All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe MacDonald <Joe_MacDonald@mentor.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH v2 0/2] netcf build fail / gnulib handling fix.
Date: Mon, 9 May 2016 10:08:33 -0400	[thread overview]
Message-ID: <20160509140831.GC21815@mentor.com> (raw)
In-Reply-To: <1462734493-3819-1-git-send-email-paul.gortmaker@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

[[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.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

  parent reply	other threads:[~2016-05-09 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-08 19:08 [PATCH v2 0/2] netcf build fail / gnulib handling fix Paul Gortmaker
2016-05-08 19:08 ` [PATCH 1/2] autotools-bootstrap: make bootstrap package specific Paul Gortmaker
2016-05-08 19:08 ` [PATCH 2/2] netcf: fix mishandling of gnulib submodule causing build fail Paul Gortmaker
2016-05-09 14:08 ` Joe MacDonald [this message]
2016-05-09 14:26   ` [PATCH v2 0/2] netcf build fail / gnulib handling fix Martin Jansa
2016-05-09 15:20     ` Paul Gortmaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160509140831.GC21815@mentor.com \
    --to=joe_macdonald@mentor.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=paul.gortmaker@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.