Re: Compile time options

[Sheldon Gill]

On Sat, 13 Mar 2004 00:59, Kazunobu Kuriyama wrote:
> 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.

Fair enough.

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

Sort of.  That the documentation isn't so good would indicate that creating 
that documentation is more work and people are currently willing to invest so 
we have an issue: "how do we facilitate documentation creation with respect 
to the configuration system"?

For many other projects I look at "./configure --help" to let me know what the 
configuration options are so that I can research them. At the moment a great 
many options don't appear for gnustep so this isn't useful.

Why isn't this being kept up to date? IMHO it's because it's too complicated 
or too much effort. I look to autogsdoc here to make my point. GNUstep went 
to the effort of creating it's own documentation tool to be able to write 
docs in-line with code.  That's why the current documentation is quite good 
and getting better all the time. It's not too hard, nor too much effort, to 
add the documentation. Further, you can add the documentation "as you go" 
rather than having to switch to working with a documentation system 
separately.

An "options.h" will allow developers to at least write a few lines about an 
option at the time of inclusion. It's the smallest amount of work.

It also makes it easier for those who come afterwards. They can expand on what 
was written before quite easily. They can also browse through the options, 
working out what they do and if they should be changed to suit a purpose. 
Further, it makes it easier to find _exactly_ what an option does because 
it's the hook used in the source.

Let me point to an example:  There's a compile time switch "BACKEND_BUNDLE" in 
NSApplication.m. What does it do? How do you change it via './configure'?  
There's nothing about it at all in './configure --help'. It's not referenced 
in Documentation.

The answer is you can't change it via configure. It's defined as an additional 
flag in the makefile's pre amble etc. Not the point, really. I ask instead 
things like:
* why is it not well documented?
* why is it not part of the configuration script?
* how do we address the root causes for the previous two questions?
* If I wanted to needed to add a similar compile time option: how am I to do 
it?  Does "BACKEND_BUNDLE" provide me with a good model to follow? If not, 
what should I do?

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

Ah, precisely my point. IMHO this is definitely the way to go for things which 
have no such dependency issue. That's why I was saying "internal to gnustep". 
I meant 'something which is entirely within the library and so has no 
external dependencies and requires no external changes'.

Yet your reply also brings up this question: you said "edit _something_". What 
is that "_something_" ?  One answer is the definition in whatever file/module 
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