configure command line in installed directories?

[Thomas Doerfler]

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.


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).
> 
> 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? Then why do we have configuration options anyway, if they 
really don't matter?

Obviously we are on totally different tracks here :-(

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.

- 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.

- 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.

- 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.

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?

> 
>>>> 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.

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?

Thomas.

> 
> Ralf
> 
> 
> 


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.