Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass

[Mike Frysinger]

On Tuesday 25 May 2010 23:59:22 Maciej Mrozowski wrote:
> On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote:
> > the library handling is incorrect.  i dont think you can pass around
> > --enable- shared all the time without having configure generate warnings
> > about unknown options.
> >
> > default to --disable-static when static-libs
> > doesnt exist is wrong -- that's the opposite of what you should be doing.
> > ignoring the same issue as the share option i mentioned above.
>
> Right. It its safe to assume that when --disable-static/--enable-static is
> available, then --disable-shared/--enable-shared is available as well?

i think that's a fair assumption.  the vast majority of shared/static 
enable/disable flags are coming in via libtool and not custom code.  the few 
packages doing custom code can simply write their own econf call.

> > the src_test func looks like its copying & pasting stuff from the PM.
> > this really should be kept in the PM without duplicating it everywhere.
>
> Unfortunately src_test needs to be called in build dir (which is unknown to
> PM).
> Calling default_src_test is the best I could come up with.

should be fine

> But what's the most important - is there any interest in having such
> eclass? I'm only going to add it when it's flexible enough to effectively
> phase-out eutils/base/autotools/libtool individual uses for fully
> autotools-controlled buildsystems. Otherwise there's no point in yet
> another wrapper imho.

personally, i probably wouldnt use this.  but i dont even like base.eclass.  
and considering other people seem to like base.eclass, it's reasonable to 
think people would like this.

the out-of-source building will trip up some packages for no reason other than 
$builddir != $srcdir, but those packages suck and should be fixed in general 
(unrelated to Gentoo).  i imagine some maintainers would be annoyed by having 
to fix these.
-mike