Re: Compile time options

[Kazunobu Kuriyama]

Sheldon,

Because your argument focued mainly on the deprecation of the configure
script, I didn't see much about possible benefits we may expect by virtue
of "options.h".  As you know, deprecating something doesn't necessarily
prove the superiority of the other.   So I intentionally enumerates the
reasons why I support "configure only" to see if "options.h + configure"
beats them.

Sheldon Gill wrote:
<snip>

> For these sorts of things, I think that using configure makes things more 
> difficult for us.
> For starters, there is the documentation issue. There is plenty in the current 
> setup which isn't documented, is poorly documented, or isn't in "./configure 
> --help".
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. :-)

> There is also the problem of having to re-run configure to change a single 
> simple option. 
I think it is rather desirable because you should check avaiable services
(e.g., headers, libraries, and so on) in accordance with the change before
invoking make.  Having the configure script do the job is conceivably the
easiest way.  If you are sure that there is no such dependency issue, you
don't need to re-run the script; type in make on the console right after
you edit something.

> 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?

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 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...

> <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? 

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.

(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.)

> 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. :-)
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.

Regards,
- Kazunobu Kuriyama