How to build Unix BSP ?

[Ralf Corsepius]

On Fri, 2003-08-01 at 23:31, Aaron J. Grier wrote: 
> On Fri, Aug 01, 2003 at 07:33:13AM +0200, Ralf Corsepius wrote:
> > On Thu, 2003-07-31 at 22:40, Aaron J. Grier wrote:
> > > what's the alternative [to RTEMS application makefile templates]?
> > 
> > How do you build applications in general? 
> 
> if they're small, like shell scripts and single-file C programs, by
> hand.  if they're larger, with makefiles.

>
> > I don't know, I can't know, I should not have to worry about.
> 
> I see your point.
My point is: Everybody has his individual approach to building
applications.

For my own work, I prefer using autoconf/automake, because that's the
environment I know and am used to.
Others might prefer individually written Makefiles (using/exploiting
their "native" make-variant), others might be using IDEs with their
tools underneath, others might be "bound" to using a developers' group's
"proprietary" or corporate infrastructure/tools/environment.

>From this point of view: RTEMS's Makefile fragments + gmake is
Joel's/OAR's proprietary, non-standardized, corporate infrastructure.
It's suffers from many drawbacks, but apparently is sufficient for
him/them.

I.e. anybody but Joel/OAR will have to "dive into the details" to find
out the details on how to use RTEMS - This is the usual thing, all
developers will have to do in almost all cases for most arbitrary
packages on almost any OS.

Furthermore, if wanting to build arbitrary 3rd-party packages for RTEMS,
RTEMS Makefile fragments don't really help. You'd either have to "dive
into the details" and find out how to propagate the appropriate details
to a 3rd-party package or you would have to port this 3rd party
package's configuration/build infrastructure to using RTEMS
Makefile-fragments/OAR's infrastructure.

> > To exaggerate: Do you use the Linux, the Solaris or the Win98
> > Kernel-Makefile-fragments for your applications?
> 
> at the very least someone using RTEMS needs to know where the libraries
> and headers are located. 
Yes, but ... is this any different from building or using any other
arbitrary package on any arbitrary OS?

IMO, no, you'd always have to find out the details.

[Example: How to build a Gnome/Gtk, KDE/Qt or X11 library or application?]

>  but things can get tricky; how do you decide
> what to link with if you want stubbed managers or debugging versions of
> libraries?
You'd have to encode this in your application Makefile rsp. to a
configuration file of the "build-tools" you are using.

Here, using RTEMS Makefile fragments help to the extend, if you are in a
position to use them. 

If you can't for some reason, you'd again have to "dive into the
details".

>   a simple -lrtemsall doesn't cover these cases.  it seems
> logical that these should be documented in some machine-readable form.
Well, these are RTEMS-specific, application-specific building details,
you currently can't avoid specifying in you application "building
script/Makefile".

> > >   automake?
> > automake is one technical alternative to help users to implement
> > Makefiles, that's all. The RTEMS makefile-fragments just another one.
> 
> are there any other alternatives?
Cf. above.

> > => All in all, this results into a pretty inflexible, error-prone and
> > hardly maintainable infrastructure.
> 
> my biggest complaint with the current makefile stubs is that they are
> somewhat twisty to read and difficult to work in a non-recursive form.
Hmm, this issue probably could be addressed by merging a BSP's *.cfgs
into one *.cfg, but (without having looked into details) I fear
addressing this once again would break backward compatibility.

Ralf