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

Re: autoconf/configure information sources?



On Thu, 18 Oct 2001, Alan Shutko wrote:

> Dale Scheetz <dwarf@polaris.net> writes:
> 
> > I've clearly found someone who "knows something" ;-)
> 
> I'm merely an autoconf apprentice....

Well, I'm somewhere below novice and it seems the upstream author is
slightly ahead of my knowledge but not yet an apprentice ;-)

> 
> > Ahh! I didn't realize this was an "added feature" by the author...
> 
> Yup.  In general, the autoconf philosophy is that it's fully
> automated, so I figured that this was author-added.  Some digging
> through configure.in showed where it was done.
> 
Yep, I found it there when I couldn't find any .m4 files in the source.

> >> * Ask upstream to put this stuff in configure flags (ie,
> >>   --enable-crash-menu)
> >> 
> > Can you expand on this a bit? (I'm just too ignorant to follow your logic)
> 
> Sure.  All of the questions asked should have command-line
> equivalents.  Ie, instead of asking whether you should enable the
> crash menu, they should use something like 
> 
> AC_ARG_ENABLE(CRASH_MENU, Whether we should enable the crash menu,
> ....

Just how many options can I put on the command line? There are more than
10 instances of this macro. Could I add one more "feature" that would
control them all (like SET_DEFAULTS) and then modify the macro to check
for this and use the defaults instead of asking the question. Then I'd
only have to --enable-SET_DEFAULTS to stop the questions. This seems to be
a solution I could then just pass upstream and see what the developer does
in reply.

> 
> which would add a command-line argument to configure.  When
> configuring, instead of being asked these questions, you'd construct a
> configure command line like
> 
> ./configure --enable-crash-menu --disable-compile-palette ....
> 
> That would be the most autoconfy way to do things like this.
> 
> It may be that the upstream really wants to ask questions, so instead
> you could lobby for some kind of "configure config file" or something,
> that the debian packaging could put into place before running
> configure.  This would require changes to their ASK_FEATURE macro.
> 
I'm not sure I'm following you here. How would this differ from my above
example solution?

> With a few changes, you could probably make it work by using
> config.cache and a modified macro, but it's really best if upstream
> were to help with this, so you don't have to do any messing in the
> future.

Agreed.

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/



Reply to: