Ralf,
Ralf Corsepius schrieb:
> On Thu, 2008-04-17 at 02:07 +0200, Pavel Pisa wrote:
>> $ gcc -v --help 2>&1 | grep conf
>> Configured with: ../../configure --prefix=/usr --with-gnu-ld --with-gnu-as --enable-shared --enable-threads=posix --enable-__cxa_atexit --verbose --with-system-zlib --disable-nls --host=i586-pc-linux-gnu --enable-bootstrap
> A completely informative textual message from an application in it help string.
>> Ask yourself: How do you technically use it?
>> You don't use it anywhere. It's only purpose is to serve as "brief
> summary" in support requests.
That's exactly the point. I _DONT_ want to feed it into any automated
process to build my application (because all the information is already
in place, thanks to your constant effort to improve the build
environment). I just want a place, where EVERY installed RTEMS has
stored, how it has been configured. And it must _ONLY_ be available in
human readable form.
>>> The file "gcc/configargs.h" holds these information in the format
>> suitable for inclusion into final binary.
> This is a temporary, internal config-header. Nothing wrong with it.
>> On a broader view, nobody denies the usefulness of config-headers.
> It actually is what I have been talking about from the very beginning of
> this thread.
>> The real issue is: What to put into exported config-headers (bspopts.h,
> cpuopts.h in RTEMS terms) and what to put into internal config-headers
> (auto-headers, aka. config.h).
>>> Same for Linux kernel, as already stated, the default
>> Linux kernel "make install" saves full configuration
>> options file in
>> /boot/config-X.Y.Z
> This is a generated configuration file of the Linux kernel's
> configuration system - a closed and isolated world of its own.
>> A special case, if you want to call it this way.
>>> So my humble personal vote is for storing command line
>> Do you?
>> You don't want "to store the command line". It's meaningless to anything
> outside of a closed world's buildsystem.
I can't speak for Pavel, but _I_ would really only like to store the
command line. And it will be very useful for _only_ two questions:
- How the hell did you configure this particular RTEMS installed here?
- How can I configure/build/install a newer version of RTEMS to match my
2 year old previous installation as close as possible
>> The problem with this thread is people lumping together different
> aspects in knee-jerk reflexs ;)
Ok, let's go back to the basics: I see a support request on the mailing
list. I guess, that the poster has somehow missconfigured RTEMS. Which
questions can I ask to prove this?
Thomas.
>> Ralf
>>> _______________________________________________
> rtems-users mailing list
>rtems-users at rtems.com>http://rtems.rtems.org/mailman/listinfo/rtems-users
--
--------------------------------------------
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.