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
code. I
will then need to make the same edit every time I update the code to a
newer
version or track my module separately and patch it myself.
I'm instead advocating moving these things to "options.h". All of my
options
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
scripts to
run configure so I could keep track of options properly. That's
after I
discovered what options were available and what they meant.
The file config.log, generated automatically by the configure script,
tells
you the things you would need. Sometimes, it reveals default options
you
didn't specify.
Thirdly, using configure becomes rather unwieldy when the command
line
gets very long.
This could be addressed by writing a small shell script which invokes
the
configure script with the options you specify, couldn't it?
That's what I said earlier: that I had to write scripts to handle
configure
scripts. I'm looking for a better option.
I guess you are writing this sort of script for keeping track of
options
and find it rather useful for system administration (e.g. rebuild or
update).
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
by
"options.h" and know what I had set. I do this with the Linux kernel
to know
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
dependency
on the platform and external libraries, too many options look like the
library
is badly designed. I'm not going to talk about this issue any more
because
this is another issue...
Sure, we can move this part to another thread...
<snip>
I propose that we separate these "internal behaviour" compile time
options
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
compile
time behaviour switches and default names/locations used by the
library.
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
configure
scirpt may change "options.h" in accordance with the information it
gathers. But how about the opposite direction? How does a change
resulting
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
external
world at all? As you know, "zero tolerance policy" is hard to keep
because
it inevitably results in conflict. I bet we will face such conflict
as
"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
inspire you.
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
the same
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
need to
make changes to a couple of other places (so that :help is supported,
for
instance).
I don't think we need that level of complexity. Probably something
closer to
ELinks which has more straight-forward definitions.
Anyway, I don't care if its called "options.h" or "feature.h" or even
if it's
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
options
can be easily defined and documented.
That will mean that the "Optional Features:" list will grow long and
some
configure lines will be very lengthy indeed. It will still make
changing
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
configure so
that the build picks up dependencies properly and is set for your
platform.
You edit options only when you want to change the *default* library
behaviours
to suit a particular set of needs.
If "configure only" and "configure + options.h" both give a similar
solution,
I prefer the former to the latter because of an obvious reason, i.e.,
it
works.
I was throwing out another possibility, but I don't think it's as good
or
easy. Don't know quite how it'll work. I was more saying I'm open to
other
possibilities and open discussion. If someone has a good idea, by all
means
speak up. Although I think a single header file for library internal
options/features is the way to go I'm not single minded.
Regards,
Sheldon
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://mail.gnu.org/mailman/listinfo/discuss-gnustep