obviously that's no good
i don't suppose there's any way out of this ? i don't suppose we could have cloog install into /usr/include/cloog/xxx instead of /usr/include/cloog-ppl/cloog/xxx ? then we wouldn't have to force any paths.
also, seems like the default --with-cloog-libdir behavior is to do -L$with_cloog/lib and since our --with-cloog doesn't include a parameter, we always link with -L/lib ?
dev-libs/cloog installs into /usr/include/cloog. It was supposed to become the default in 4.6, then again in 4.7, now maybe 4.8... dev-libs/cloog-ppl was supposed to be a temporary fork but just won't die. The upstream version will probably work with 4.6+, but not 4.4/4.5.
could you add some comments to the eclass documenting this ugliness ?
i guess we'll have to live with the -I stuff for now, but the -L/lib should get fixed (unless i read the configure scripts wrong)
(In reply to comment #1)
> dev-libs/cloog installs into /usr/include/cloog. It was supposed to become
> the default in 4.6, then again in 4.7, now maybe 4.8...
I think it finally happened, see $URL and bug 434816 (though I cannot reproduce it, i.e. current HEAD compiles fine for me with cloog-ppl)
Yep, when I get some time I need to update the eclass for cloog in 4.8 and slot ppl for older versions (the dlopen patch is ppl version specific).
*** Bug 438624 has been marked as a duplicate of this bug. ***
(In reply to Ryan Hill from comment #4)
> Yep, when I get some time I need to update the eclass for cloog in 4.8 and
> slot ppl for older versions (the dlopen patch is ppl version specific).
This is fixed. Ryan did you forget to close this bug:
Unless you want to leave this bug open for pre 4.8?
i think we'll just drop graphite support in <gcc-4.8 once we finish stabilizing
dropped via bug 448024