dennisveatch at bellsouth.net
Wed Mar 25 17:38:26 CET 2009
On Tuesday 24 March 2009 7:29:43 am Dennis Veatch wrote:
> On Monday 23 March 2009 10:55:53 pm Auke Kok wrote:
> > Jannis Pohlmann wrote:
> > > Hey guys,
> > >
> > > I don't want to go off-topic here, but could anyone please comment on
> > > the default_python_build and init.d detection patches I sent to this
> > > list a bit more than a week ago?
> > in principle all those patches are ok, but like the cmake one, we have
> > to maintain some basic rules for these:
> > 1 - clear difference between "configure" and "build" phases, and run
> > prepare_install in between
> I think the proposed cmake stuff adheres to that.
> > 2 - prefer GNU make over other build systems by default (IOW, if
> > 'Makefile' exists use it, instead of attempting a CMake build just
> > because 'configure' did not exist).
> I don't know of any module that has only a Makefile and does not have a
> BUILD. So it will be a given a BUILD will exist. Which will cause;
> if has_module_file $MODULE BUILD ; then
> run_module_file $MODULE BUILD
> in the run_build function to kick in before it even thinks about going on
> to default_build, default_cmake_build, or default_python_build. So I don't
> atm see that as being a problem.
> > I haven't looked too closely in all the examples flying by, but I can
> > see about merging them in theedge and taking a close look myself to make
> > sure we don't break any modules expecting above behaviour.
> > Auke
> > _______________________________________________
Here is a slight change. It renames default_cmake to default_cmake_config to
accurately reflect its function. Also added to this function the out of place
You can tuna piano but you can't tune a fish.
It's worth the spin.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1204 bytes
Desc: not available
More information about the Lunar-dev