enabling/disabling features

[Couannette]

I completly agree with you analysis.
Much work still resides in applications code.
Dependency code in Lunar is great.
We should simply identify dependencies that are actualy optional but
implemented as normal.
Could you make me an excerpt of Lunar code that handle configure
--enable and --disable things. With some clues about the way lin
operate. Thank you in advance.

Couannette

Auke Kok wrote:

>On Wed, 2003-07-02 at 14:51, Nick Hudson wrote:
>  
>
>>The current way
>>of doing the deps isnt the end all and yes it can be worked on and it
>>will get better once Lunar2 starts some major development.
>>    
>>
>
>I will go a little step further to make sure you're not discussing
>something that already exists for about 2 years:
>
>Lunar's dependency code is not at discussion here, it provides all the
>features you asked for already. It is now up to the developers to make
>moonbase even more correct by filling in the optional_depends as much as
>possible, and there are some slight gaps in there.
>
>Most of the blame goes to the source code itself, lunar provides the
>features and though we may not have hit the spot on every module yet, it
>is perfectly capable of that....
>
>If you find required dependencies that are in fact optional, 
>
>    LET US KNOW
>
>by either sending in a patch, pulling the pants of a developer or
>joining us in #lunar on irc.freenode.net!
>
>on lunar2/future development: there will be no major structural
>dependency code improvements, simply because it really cannot be done
>much better than it is done right now!
>
>Terry wrote on auto[conf|make]:
>" No this is mostly NOT true,  programs that remove autoconf and
>automake are for the most part an ERROR in moonbase, and exceptions
>should be fixed ASAP."
>
>This is correct, but the main reason is that removing autoconf used to
>be a quick hack to fix a broken module. The main caveat is that the
>private autoconf structure of the corresponding source code is
>old/outdated, something that has become a larger problem with modules
>becoming outdated and unmaintained.
>
>[Ref: try to build svgalib against gcc-3.3]
>
>Bottom line is that we're better off with you guys digging in our
>modules dependencies, and if you something you don't like, tell us!
>
>sofar
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lunar mailing list
>Lunar at lunar-linux.org
>http://lunar-linux.org/mailman/listinfo/lunar
>  
>