[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
configure command line in installed directories?
- Date: Thu, 17 Apr 2008 11:00:21 -0400
- From: rsg at alum.mit.edu (Robert S. Grimes)
- Subject: configure command line in installed directories?
Thomas Doerfler wrote:
> Ralf Corsepius schrieb:
>> 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.
EXACTLY! (Pardon my shouting! This is exactly what I would ask for
with respect to my original question, which Thomas generalized in the
original posting of this thread. Sure, it is not technically needed.
Sure, an experienced, diligent sys admin would capture this information
anyway. But what is wrong with a simple, automated, standardized
capture of this information?
And it can be as simple as copying the config.log file to the
installation point - even though extra, unneeded information may well be
>> 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).
Yes, and it would be helpful to point out these (exported) files
existence, their importance, etc., so that new users _know_ where the
_best_ sources of information that an application developer really
_does_ need to know.
>> 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
Agreed, these are the original questions I had...
> 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?
As a frequent poster with "support requests", especially before I gained
the experience to understand the importance of such information, being
asked to "post <installpoint>/config.log" is a _lot_ easier than "how
did you configure RTEMS". I am purposely taking the viewpoint of a
novice here, because I remember my early days here. Anything that can
reasonably done to make it easier to new users will make RTEMS more
widely used. Perhaps even more important, if you assume a growing user
base, is anything that can be done to help experts get the information
they need to help the new users should be appreciated by said experts,
even if the experts don't need or use such aids. Without speaking for
Thomas, I believe this is his point here.
So, in summary, what is wrong with simply "installing" config.log into
the install point, in the appropriate BSP directory?