[oe] [PATCH v2 0/2] netcf build fail / gnulib handling fix.

[Paul Gortmaker]

[Re: [PATCH v2 0/2] netcf build fail / gnulib handling fix.] On 09/05/2016 (Mon 16:26) Martin Jansa wrote:

> On Mon, May 09, 2016 at 10:08:33AM -0400, Joe MacDonald wrote:
> > [[PATCH v2 0/2] netcf build fail / gnulib handling fix.] On 16.05.08 (Sun 15:08) Paul Gortmaker wrote:
> > 
> > > In the previous version[1] of the attempt to fix the netcf build on
> > > newer hosts, Martin noted that my change broke fontforge.
> > > 
> > > The reason for that is the ./bootstrap in fontforge is older and
> > > doesn't support the "--no-git" option I used for netcf.
> > > 
> > > This highlighted the fact that we will want to be able to use
> > > different args to the ./bootstrap for different packages.
> > > 
> > > The first commit moves the configure_prepend step as-is out to
> > > the packages, so we can do the above, and thus making
> > > autotools-bootstrap unused in the process.
> > > 
> > > The second commit fixes the netcf prepend to not overwrite
> > > contents from the netcf package itself, which was the source
> > > of the build failure.
> > > 
> > > The functionality of the prepend for fontforge is left as-is
> > > so that it will continue to build w/o issue.
> > 
> > I've no objection to this change, it seems sensible and low-impact to
> > me.  That said, if there's any objection to removing the
> > autotools-bootstrap class, I'd also support a version of this that
> > leaves the class but divorces netcf from it.
> > 
> > I wonder, though, now that I'm thinking about it, if the crux of the
> > change is going from:
> > 
> >  21     # | ...
> >  22     ./bootstrap --force
> >  23     cd $currdir
> >  24 }
> > 
> > to something like:
> > 
> >  21     # | ...
> >  22     ./bootstrap --force --no-git --gnulib-srcdir=.gnulib
> >  23     cd $currdir
> >  24 }
> > 
> > with the extra logic around the "rmdir .gnulib" being somewhat
> > peripheral, would it be possible to extend the class instead with a new
> > varaible that would be set in the respective recipe file, using, say,
> > breakpad.bbclass as an example?
> > 
> > What I'm thinking of here is something like this:
> > 
> > >>> do_configure_prepend() {
> > >>>     currdir=`pwd`
> > >>>     cd ${S}
> > >>> 
> > >>>     rmdir ${S}/.gnulib || cat >.gitmodules <<EOF
> > >>> [submodule "gnulib"]
> > >>>    path = gnulib
> > >>>    url = git://git.sv.gnu.org/gnulib
> > >>> EOF
> > >>>     if [ -d ${S}/.gnulib ] ; then
> > >>>         cp -rf ${STAGING_DATADIR}/gnulib ${S}
> > >>>     else
> > >>>         cp -rf ${STAGING_DATADIR}/gnulib ${S}
> > >>>     fi
> > >>> 
> > >>>     # --force to avoid errors on reconfigure e.g if recipes changed we depend on
> > >>>     # | bootstrap: running: libtoolize --quiet
> > >>>     # | libtoolize:   error: 'libltdl/COPYING.LIB' exists: use '--force' to overwrite
> > >>>     # | ...
> > >>>     ./bootstrap --force ${BOOTSTRAP_EXTRA}
> > >>>     cd $currdir
> > >>> }
> > 
> > then in fontforge, just leave everything as-is (until it gets a review /
> > update / whatever) and in netcf's recipe we just add a line:
> > 
> >    BOOTSTRAP_EXTRA = "--no-git --gnulib-srcdir=.gnulib"
> > 
> > Obviously the above is all un-tested and mostly just off-the-top-of-
> > my-head thinking, so maybe it's completely unworkable.  If Martin is
> > okay with the patches as sent, I'm fine with them too.
> 
> I'm fine with current patches, but was wondering the same, why not
> introduce variable so that the same bbclass can be used by both "new"
> and "old" bootstrap versions.

I did consider a solution along the lines of the above, but the more I
thought about it, and looked for users outside OE (e.g. Yocto) the more
I came to the conclusion that the class was largely a solution looking
for a problem.  There are just these two users of the class now.  

Anyone trying to use gnulib (which BTW is meant to help build GNU source
on non-GNU systems -so hopefully it remains uncommon) is most likely going
to have to do some custom pre-config [e.g. create submodule file or not]
so the class boils down to infrastructure for one bootstrap line to be
"shared".

> 
> But I don't know anything about this bootstrap, so cannot say if we can
> expect only these 2 variants or if every bootstrap usage is really
> specific to given recipe and not worth sharing the common part in bbclass.

Per above, I think it is safe to say we won't see hundreds of gnulib
users, and speaking only for myself, the fact it was a class to begin
with led me down the wrong path thinking that I should fix the sharing
by standardizing on a common bootstrap etc. etc. which was ugly.

Here we retain the value of not downloading gnulib multiple times, and
we give the pkgs full independence on how they handle bootstrap without
trying to confine them into what we predict they might need.

Paul.
--

> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com