discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compile time options


From: Alex Perez
Subject: Re: Compile time options
Date: Sat, 13 Mar 2004 10:37:15 -0800

Sheldon,

You're making a hell of a lot of assumptions that are unwarranted....read below

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"?
Yes, it could. Lots of GNUstep developers have the "documentation isn't worth my (limited) time" complex, and you're not taking that into account.

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

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.
You're making too many assumptions about other people's time, and it makes you look bad.

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

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.
I have no problem if configure *creates* options.h. I think it's really shortsighted do have an independent options.h file though.

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

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?
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 to do it? Does "BACKEND_BUNDLE" provide me with a good model to follow? If not,
what should I do?
Any core developers care to comment?

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
A dynamically generated options.h, made BY configure. it's called configure.h
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
address@hidden
http://mail.gnu.org/mailman/listinfo/discuss-gnustep

--
Alex Perez
address@hidden
"Error of opinion may be tolerated where reason is left free to combat it."
--Thomas Jefferson





reply via email to

[Prev in Thread] Current Thread [Next in Thread]