[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compile time options
Re: Compile time options
Sat, 13 Mar 2004 10:37:15 -0800
You're making a hell of a lot of assumptions that are
Yes, it could. Lots of GNUstep developers have the "documentation isn't
worth my (limited) time" complex, and you're not taking that into
This could be addressed by someone's writing a good document about it,
couldn't it? (The starters don't like to read a detailed document.
Sort of. That the documentation isn't so good would indicate that
that documentation is more work and people are currently willing to
we have an issue: "how do we facilitate documentation creation with
to the configuration system"?
We use configure. Period. We don't need options.h unless it is
*generated* by Configure. We do *NOT* need two different and
unconnected places to do the same thing. I think all of the stuff
you're talking about, *ALL* of it, should be simply a part of a
configure script. If it generates an options.h file, thats fine, but
two disparate places to set compile time options is nothing short of
stupid, since we already have a standard mechanism for dealing with
that sort of stuff. Saying "Some things aren't in configure so we
should use options.h for them" is simply a bad excuse. Those instances
where things are NOT set up by configure should be fixed to use
For many other projects I look at "./configure --help" to let me know
configuration options are so that I can research them. At the moment a
many options don't appear for gnustep so this isn't useful.
You're making too many assumptions about other people's time, and it
makes you look bad.
Why isn't this being kept up to date? IMHO it's because it's too
or too much effort. I look to autogsdoc here to make my point. GNUstep
to the effort of creating it's own documentation tool to be able to
docs in-line with code. That's why the current documentation is quite
and getting better all the time. It's not too hard, nor too much
add the documentation. Further, you can add the documentation "as you
rather than having to switch to working with a documentation system
I'm not arguing that, but it's also completely sub-optimal and
non-elegant and it doesn't fit in with the system (configure) that we
already have. Whether or not we're using that as much as we should is
debatable, but it's a separate (albiet connected) issue.
An "options.h" will allow developers to at least write a few lines
option at the time of inclusion. It's the smallest amount of work.
I have no problem if configure *creates* options.h. I think it's really
shortsighted do have an independent options.h file though.
It also makes it easier for those who come afterwards. They can expand
was written before quite easily. They can also browse through the
working out what they do and if they should be changed to suit a
Further, it makes it easier to find _exactly_ what an option does
it's the hook used in the source.
This probably makes the backend compile as a bundle if it's turned on.
It's probably experimental, but it should probably be a configure
option *looks to Alex M.*
Let me point to an example: There's a compile time switch
NSApplication.m. What does it do? How do you change it via
There's nothing about it at all in './configure --help'. It's not
The answer is you can't change it via configure. It's defined as an
flag in the makefile's pre amble etc. Not the point, really. I ask
* why is it not well documented?
Time. Not really a good excuse, but it's understandable.
* why is it not part of the configuration script?
No good reason, as it should be.
* how do we address the root causes for the previous two questions?
Add more hours to the day ;-)
* If I wanted to needed to add a similar compile time option: how am I
it? Does "BACKEND_BUNDLE" provide me with a good model to follow? If
what should I do?
Any core developers care to comment?
Yet your reply also brings up this question: you said "edit
is that "_something_" ? One answer is the definition in whatever
A dynamically generated options.h, made BY configure. it's called
you wish to change. That would mean I need to find the definition I'm
interested in, firstly. So I must spend time trawling through the
will then need to make the same edit every time I update the code to a
version or track my module separately and patch it myself.
I'm instead advocating moving these things to "options.h". All of my
will be there and so I can more easily manage these things.
You need to know exactly how configure was last invoked to
re-configure it correctly. For other projects I've had to write
run configure so I could keep track of options properly. That's
discovered what options were available and what they meant.
The file config.log, generated automatically by the configure script,
you the things you would need. Sometimes, it reveals default options
Thirdly, using configure becomes rather unwieldy when the command
gets very long.
This could be addressed by writing a small shell script which invokes
configure script with the options you specify, couldn't it?
That's what I said earlier: that I had to write scripts to handle
scripts. I'm looking for a better option.
I guess you are writing this sort of script for keeping track of
and find it rather useful for system administration (e.g. rebuild or
Keeping both a note on options used and "options.h" somewhere for this
purpose would makes a thing a little bit harder.
I think it'd make things somewhat easier. I can simply have a copy of
"options.h" and know what I had set. I do this with the Linux kernel
what build options I'd used.
I believe that the difficulty in setting things at compile time is
resulting in fewer options within the library.
Hmm...this sounds controversial. Other than the options related to
on the platform and external libraries, too many options look like the
is badly designed. I'm not going to talk about this issue any more
this is another issue...
Sure, we can move this part to another thread...
I propose that we separate these "internal behaviour" compile time
from autoconf and put them in per library "options.h" or something
similar. That can be the place to define all sorts of things like
time behaviour switches and default names/locations used by the
Documentation for each item could then be in-line making it easier to
create and maintain.
Though it logically looks sound, how do you implement this? The
scirpt may change "options.h" in accordance with the information it
gathers. But how about the opposite direction? How does a change
from editing "options.h" is reflected on the configure script?
No, the configure script is not to touch "options.h" at all.
Or does "options.h" only contain stuff which is irrelevant to the
world at all? As you know, "zero tolerance policy" is hard to keep
it inevitably results in conflict. I bet we will face such conflict
"options.h" gets matured.
Options is only to contain stuff irrelevant to dependencies and other
libraries. It's for "library internal" things.
(To address this problem, the building scheme adopted by VIM might
In fact, I always build it after editing src/feature.h; I don't use
the configure script at all for that.)
I suspect you've just agreed with my argument. I'm talking about just
sort of thing. VIM isn't the only one to have it.
For VIM, there is a lot more to adding a "feature" properly. You also
make changes to a couple of other places (so that :help is supported,
I don't think we need that level of complexity. Probably something
ELinks which has more straight-forward definitions.
Anyway, I don't care if its called "options.h" or "feature.h" or even
separated into multiple headers. It is the concept that is important.
Another possibility would be to extend autoconf, possibly just by
additional m4 scripts, to source a file or directory where such
can be easily defined and documented.
That will mean that the "Optional Features:" list will grow long and
configure lines will be very lengthy indeed. It will still make
options somewhat annoying as you'd need to re-run configure.
But tweaking both configure and options.h looks annoying as well. :-)
Looks perhaps but I think you'll find the practice different. You
that the build picks up dependencies properly and is set for your
You edit options only when you want to change the *default* library
to suit a particular set of needs.
If "configure only" and "configure + options.h" both give a similar
I prefer the former to the latter because of an obvious reason, i.e.,
I was throwing out another possibility, but I don't think it's as good
easy. Don't know quite how it'll work. I was more saying I'm open to
possibilities and open discussion. If someone has a good idea, by all
speak up. Although I think a single header file for library internal
options/features is the way to go I'm not single minded.
Discuss-gnustep mailing list
"Error of opinion may be tolerated where reason is left free to combat
Re: Compile time options, Adam Fedor, 2004/03/14