configure command line in installed directories?

[Ralf Corsepius]

On Mon, 2008-04-14 at 09:40 +0200, Thomas Doerfler wrote:
> Ralf,
> 
> Ralf Corsepius schrieb:
> > Recording and hard-coding configure-arguments is a silly idea, because
> > configure-arguments only have a meaning to a local source tree.
> 
> I am not talking about hard-coding. But my understanding is, that 
> "configure" has a set of options, and at least some of them are 
> meaningful and make sense (although some of them ARE questionable). Some 
> of these options _do_ modify the generated code (e.g. 
> "--target=sparc-rtems4.8" or "--enable-rtemsbsp=..." or 
> "--enable-multiprocessing" or .....)
> 
> And the generated code will differ depending on these options (e.g. 
> depending whether multiprocessing is on or off).
Correct. I guess I need to point out the obvious:

Applications do NOT see the sources! They see headers and they see
libraries.
=> You need to check headers and libraries

 
> > They are meaningless to anything outside of the particular sources,
> > because a library package (such as RTEMS) has no knowledge about what
> > infrastructure users might be using.
> 
> Right, but in the scenario I am looking at the term "user" is not a 
> single guy who selects the options properly for his project. I am 
> thinking about a team which develops a bigger project and may even be 
> spread over several companies.
What has this got to do with your issue?

How do you use you host os across companies? ... by shipping binaries,
by sharing binaries/headers ...

I really fail to see your arguments.

>  One of the team members might configure 
> and build RTEMS for the proper architecture and will select a option set 
> during configuration which seems right from his point of view. He 
> _should_ document, what he has done, but having an automated way to 
> document, how the RTEMS tree has been configured before a particular 
> build, might help.
> 
> I agree, that this will no longer be needed, when the configure options 
> do NOT influence the generated libraries.

configure options will always influence the generated libraries - EVER.

There is no way around it - EVER.

> >>  If you think about a team working with 
> >>   an installed version of RTEMS, for a given project, I regard it 
> >> preferable that everybody can find out how RTEMS has been configured.
> > No - Nobody needs this kind of information.
> > 
> > What people need is information on "features a package has built-in".
> 
> Right. How do I find out currently? I can pull many things from various 
> places (e.g. "bspopt.h"),
Correct, but you are supposed to never do so.

>  but I did not yet find a documentation stating 
> "this configure option can be retrieved from that file".
Because you will never have to do so - There is no need to do so.

Application can simply reuse these defines without any further measures
(ifdef foo ....), configure scripts can check for presence of these
settings, etc.

> >> And AFAIK the build directory is a temporary one, so in general it can 
> >> be removed after the built files have been installed.
> > Correct, it's temporary and so are configure-arguments - They should not
> > be of interest to anybody.
> 
> Not even for support on the mailing list? So, when a newbie reports some 
> problems, the question "how did you configure RTEMS before build?" is a 
> meaningless question?
Yes, because defaults are supposed to be safe.

If your BSP doesn't build out of the box, it's broken.

Ralf