Module submissions: accept/reject checklist ?

Duncan Gibson duncan.gibson at xs4all.nl
Thu Apr 21 21:33:56 CEST 2011


Me:
>> 1: What do people think about the --disable-static changes? Is there a
>>    better way to achieve this that is not hard-coded and does not affect
>>    everyone?

Ratler:
> We should make this a global option, but I'm not so sure all configure
> scripts have this option which might cause it to fail. Once investigated
> it would be pretty easy to implement that feature. The same could also
> be done for documentation, I have some ideas how it could be implemented
> on a module level.

I have half an idea about this, but I'm not sure how it scales up if there
are (a) different ways of achieving the same thing, or (b) there are lots of
different options that need to be supported.

Let's assume that modules that have some means of turning off building the
static libraries use configure, and that the option is --disable-static or
a similar simple string. We could create a GLOBAL_DISABLE_STATIC option that
can be toggled on/off from the lunar menu (default is off). We would also
need to add a local DISABLE_STATIC variable in the DETAILS of each module
that offered a --disable-static like option. When the module is built, the
inner levels of default_build() check to see that GLOBAL_DISABLE_STATIC is
ON and DISABLE_STATIC is not empty, and then adds the value to OPTS before
calling default_config().

As far as I can see this will handle the case where there are different
ways of specifying --disable-static. If you do need to --enable-static for
a particular module, you could still use lin -rc --opts="--enable-static".

Where it falls down is that you need a GLOBAL_OPTION and an OPTION for all
of the options that you might want to set, --disable-static, --disable-docs,
--disable-gobject-introspection, etc. And this system assumes the module is
built using configure, and not cmake, nor scons, or any of the other build
systems that are available.

I'm not sure about the inner workings of the lunar code so there might be
a better way of doing this. The names of the variables are suggestions.

That's my 2 cents worth, anyway.

Cheers
Duncan / engelsman



More information about the Lunar-dev mailing list