configure command line in installed directories?

[Ralf Corsepius]

On Mon, 2008-04-14 at 11:50 +0200, Thomas Doerfler wrote:
> Ralf,
> 
> maybe I need to clarify my initial request a bit:
> 
> With my request I only want to "document" to explicitly selected 
> configure options, not the ones implicilty choosen and/or passed through 
> the source code directory hirarchy.

Let's get to the point: Which of these flags do you have in mind?


> Ralf Corsepius schrieb:
> > 
> > How do you use you host os across companies? ... by shipping binaries,
> > by sharing binaries/headers ...
> 
> Or by shipping RPMs, which include their dependencies AND the 
> information how they have been built/how they can be rebuilt (even when 
> they do NOT contain the sources).
Correct. RPMS are a form of *packaging*.

Packaging is something completely different than configuration and is
something completely different than "system-integration".

Could it be you are mixing up, system-integration, packaging and
configuration?

> > 
> > configure options will always influence the generated libraries - EVER.
> > 
> > There is no way around it - EVER.
> > 
> 
> >>> 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.
> 
> So you really mean I don't have to care about how RTEMS has been 
> configured?
Yes. That's how things are supposed to work.

It's supposed to be not any different from how you work with other
libraries elsewhere.

As application developer you should not have to care how glibc, gcc,
gtk, kde or whatever have been configured.


>  Then why do we have configuration options anyway, if they 
> really don't matter?
configuration != system integration.

system integrators use configure scripts to adapt a package to a
system's conventions (--prefix ....), enable/disable certain features,
etc.

Application developer use what system-integrator set up from them.

> Obviously we are on totally different tracks here :-(
Seems to be so.

> An example:
> 
> Let's stick to the option "--enable-multiprocessing".
> 
> - The guy in my team, who configured/built RTEMS, has forgotten to 
> enable this option, so RTEMS will not support multiprocessing.
Correct. The system-integrator having set up your environment made a mistake.

The rtems source tree can be configured in incompatible ways. Or
differently, the rtems source tree contains multiple source-trees folded
into one. It's a system-integrators job to find an installation layout
to not mix them up.

[It's essentially the same as with gcc: Several conflicting toolsets
folded into one source tree.]

> - I have designed my application in a way that it needs multiprocessing. 
> This will not avoid that my applications link fine, because at least the 
> Classic API will only find out about the mismatch during runtime.
Then you need to ask your system integrator/admin to provide you with
the infrastructure you need and to equipe your applications with means
such that they "degrade gracefully" or bomb out if the infrastructure
doesn't match these applications' expectations.

It's not any different from, wanting to build a gtk application against
kde - You need the gtk-devel environment, kde-devel won't help you.

You want a "multiprocessing" enabled rtems, a "non-multiprocessing"
rtems won't help you.


> - I will download my application modules to various nodes and then will 
> get some obscure errors when trying to create/use global objects on 
> other nodes.
That's a different class of issues - Runtime behavior.

> - You are right that the information, that multiprocessing is disabled, 
> is somewhere in one of the headers (cpuopt.h), and I might write my 
> applications in a way that the code adapts to the fact, that 
> multiprocessing IS disabled, but that is not what I want anyway.
Exactly. You can use these defines as last resort to let building your
application fail. 

When using autoconf you could let building your application fail early.


> So after some time I will start to ask questions: "Why do I have a 
> problem using global objects", and having a look at how RTEMS has been 
> built may give me one hint. Agreed?
No idea which global objects you are referring to.

The global objects you mention above? => Same answer as before.

 
> >>>> 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.
> 
> Agreed. But I am NOT only talking about defaults.
And where is the problem?

If you are building with no-standard options, you are not building
standard-rtems. You are building the "embedded-brains distribution" of
RTEMS and will have to develop your own conventions to integrate this
distribution such that it is usable for you.

It's not any different from what distribution vendors do in general.

They set up their tools to provide a consistent distribution.

> So, I am willing to move my position:
> - If the user does not have to care about how RTEMS has been configured, 
> then I vote to remove ALL explicit configuration options.
> 
> Does this make more sense?
No, it doesn't - You don't seem to have understood the purpose of
configure options ("adaption to a particular system") and between
configuration and packaging/system-integration.

Ralf