Hi Ward,
On 12 Jul 2013, at 17:41, Ward Poelmans wrote:
> Hello all,
>
> I want to make a new eb for gcc that builds with the latest cloog and
> ppl. The problem is that I need to apply a patch to ppl before
> building in stage 2. And that's a problem (I think). Currently, the
> sources of gcc, cloog, ppl, ... are all extracted in the same
> directory and just before building in stage 2, the sources of cloog
> and ppl are moved to in-tree.
>
> My question is, what is the best way to apply a patch to ppl? I think
> there are 2 ways:
> - I can add a patch_step to the gcc easyblock that reads that patches
> and applies them according to prefix: ppl-* is applied to the ppl
> tree, cloog-* is applied to the cloog tree.
> - Currently, you can specify either a patch level or a prefix to a
> patch in an easyconfig. This could be extended to allow both? This
> would also solve my problem. A prefix alone is not enough for the
> patch I want to apply.
>
> Does anyone have an opinion on which way to proceed?
I trust you were able to specify the patch file for PPL using "patches = [
('ppl-mpfr.patch','../ppl-%s' % pplver)]", right?
> Futher I have a small suggestion for the FAQ on github: if you have
> cuda in your CPATH, C_INCLUDE_PATH or LIBRARY_PATH, you can get weird
> gcc building errors. So, I think it's a good idea to unset those
> variables prior to building gcc if you get any strange error.
Is there any reason why we shouldn't unset $CPATH, etc. in the GCC easyblock,
prior to building GCC?
That's what an easyblock is for: implement all that is required to make a build
work, and then forget about it.
Better that than document it in some obscure corner of the web (e.g., the
EasyBuild FAQ), and hope that Google leads you to it if you run into the
problem.
@Ward: Are you up to creating a PR for this? I would unset $CPATH etc. during
the GCC build, but make sure the original values are restored after the GCC
build (just in case they're required for other builds in the same run).
Maybe we should even make this a generic feature, i.e. implement it in the
framework somewhere, and simply supply a list of variable names that should be
unset during a build. $DISPLAY is a another example of this pattern, and I'm
sure there are others...
K.
