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
signature.asc
Description: This is a digitally signed message part.
