configure command line in installed directories?

[Joel Sherrill]

I can't believe that I can going to argue both sides of
this one but please read the entire message. :-D

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.
>   
We often ask "how did you configure RTEMS?" as part of
answering a question.  Having some way to get this information
from an installed RTEMS environment (not just RTEMS itself)
doesn't seem like a bad idea from a support view.

We could have a program/script that
queried the RTEMS environment and tools and produced
a report including host OS, tool versions, RTEMS options,
etc.  How this information is gathered could be flexible.
A simple native C program COULD safely include the RTEMS
cpuopts.h and bspopts.h if it didn't include anything else.

Ralf.. didn't you used to send a script out for cygwin problems?

But to shoot a hole in Thomas' example, read further.
> 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?
>
>   
Unfortunately, I can address this case without installing the
configure options. 

Most of the --enable options would result in link errors or
possibly larger than expected executables if features were
enabled, you didn't need.

When I see user configuration errors, I have been trying to
think of ways where confdefs.h can catch them at compile
time.  This is a fairly recent path and I only add cases as I
get user problems that I realize could have been caught.

For example, right now, if you don't configure an initialization
tasks/threads, it  gives you an error.

In your example, you would have HAD to specify some
multiprocessing configuration options and confdefs.h
could have recognized that it wasn't configured. 

This could apply to POSIX objects as well.  It you configure
any and POSIX is disabled,  it could be an error.

I have been thinking about the common "no clock driver"
problem.  One thought I had was to make you specifiy
"NO_CLOCK_DRIVER" and if you didn't explicitly configure
the clock driver in or out, you would get an error.  Similarly,
if you say clock driver and microsecond per tick is 0, then
there is an error.

I am pretty sure there are many inconsistencies that could
be caught by confdefs.h.

--joel