Created attachment 279685 [details] path64-suite-9999.ebuild after the insertion of ekopath-bin to portage, I sumbit here my ebuild for path64-suite. you'll need to patch cmake.eclass so copy it to your local overlay. do note that this patch for cmake.eclass doesn't affect other packages. in an essence, this ebuild allows one to build path64 for the first time with either gcc or ekopath-bin (user defined). after first successful compilation, the choice will be either gcc or path64. I'm not going to insert it to sunrise because it needs cmake.eclass change which might not pass gentoo's qa. this ebuild was tested successfully with ekopath-bin and path64 on amd64. my only TODO left is to instruct the ebuild to install path64 under /usr/lib/ekopath and not /usr/lib/4.0.10 as it is happening now. I hope I'll get to it soon. enjoy.
Created attachment 279687 [details] cmake.eclass.patch patches cmake.eclass to enable ekopath compilation.
Cool, thanks for making this. Why not try submitting to sunrise and see what the devs say? They might have some advice for getting around the cmake.eclass issue in a 'correct' way.
(In reply to comment #2) > Cool, thanks for making this. Why not try submitting to sunrise and see what > the devs say? They might have some advice for getting around the cmake.eclass > issue in a 'correct' way. there isn't... check the cmake eclass. as for the path changes, I've been able to correct most of the paths, the rest seems to cause the compilation to fail.
Does it build and work on ~x86 for anyone?
(In reply to comment #4) > Does it build and work on ~x86 for anyone? try it :) the official configure script says that it isn't supported but the cmake files seems to support it. try it out, worst case, nope, best case yes.
(In reply to comment #5) > (In reply to comment #4) > > Does it build and work on ~x86 for anyone? > > try it :) If it would be that simple, I hadn't asked. ATM I am on gprs connection only for the next two weeks. I tried ssh to my desktop, but with current connection latencies it is a pain to work even with ssh -C. But I'm curious if it forks, that's why I asked. Let's say I really want to see good competition with gcc.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Does it build and work on ~x86 for anyone? > > > > try it :) > > If it would be that simple, I hadn't asked. > ATM I am on gprs connection only for the next two weeks. I tried ssh to my > desktop, but with current connection latencies it is a pain to work even with > ssh -C. > > But I'm curious if it forks, that's why I asked. Let's say I really want to see > good competition with gcc. I tried to compile on i686, but it caught segfault.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > Does it build and work on ~x86 for anyone? > > > > > > try it :) > > > > If it would be that simple, I hadn't asked. > > ATM I am on gprs connection only for the next two weeks. I tried ssh to my > > desktop, but with current connection latencies it is a pain to work even with > > ssh -C. > > > > But I'm curious if it forks, that's why I asked. Let's say I really want to see > > good competition with gcc. > > I tried to compile on i686, but it caught segfault. the compilation or the resulting bin?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > (In reply to comment #4) > > > > > Does it build and work on ~x86 for anyone? > > > > > > > > try it :) > > > > > > If it would be that simple, I hadn't asked. > > > ATM I am on gprs connection only for the next two weeks. I tried ssh to my > > > desktop, but with current connection latencies it is a pain to work even with > > > ssh -C. > > > > > > But I'm curious if it forks, that's why I asked. Let's say I really want to see > > > good competition with gcc. > > > > I tried to compile on i686, but it caught segfault. > > the compilation or the resulting bin? the compilation: [ 7%] Generating check_combos.c, implicits.c /bin/sh: line 1: 31046 Segmentation fault ../../bin/table < /home/ak/path64-suite/build/Xcompiler/src/driver/OPTIONS.P make[2]: *** [Xcompiler/src/driver/check_combos.c] Error 139
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > (In reply to comment #5) > > > > > (In reply to comment #4) > > > > > > Does it build and work on ~x86 for anyone? > > > > > > > > > > try it :) > > > > > > > > If it would be that simple, I hadn't asked. > > > > ATM I am on gprs connection only for the next two weeks. I tried ssh to my > > > > desktop, but with current connection latencies it is a pain to work even with > > > > ssh -C. > > > > > > > > But I'm curious if it forks, that's why I asked. Let's say I really want to see > > > > good competition with gcc. > > > > > > I tried to compile on i686, but it caught segfault. > > > > the compilation or the resulting bin? > > the compilation: > [ 7%] Generating check_combos.c, implicits.c > /bin/sh: line 1: 31046 Segmentation fault ../../bin/table < > /home/ak/path64-suite/build/Xcompiler/src/driver/OPTIONS.P > make[2]: *** [Xcompiler/src/driver/check_combos.c] Error 139 are you compiling with native flag on?
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > (In reply to comment #6) > > > > > (In reply to comment #5) > > > > > > (In reply to comment #4) > > > > > > > Does it build and work on ~x86 for anyone? > > > > > > > > > > > > try it :) > > > > > > > > > > If it would be that simple, I hadn't asked. > > > > > ATM I am on gprs connection only for the next two weeks. I tried ssh to my > > > > > desktop, but with current connection latencies it is a pain to work even with > > > > > ssh -C. > > > > > > > > > > But I'm curious if it forks, that's why I asked. Let's say I really want to see > > > > > good competition with gcc. > > > > > > > > I tried to compile on i686, but it caught segfault. > > > > > > the compilation or the resulting bin? > > > > the compilation: > > [ 7%] Generating check_combos.c, implicits.c > > /bin/sh: line 1: 31046 Segmentation fault ../../bin/table < > > /home/ak/path64-suite/build/Xcompiler/src/driver/OPTIONS.P > > make[2]: *** [Xcompiler/src/driver/check_combos.c] Error 139 > > are you compiling with native flag on? neither on, nor off: just clone it from github, configure and make. i tried to do it with gcc 4.6, but now i see that 4.2 must be used, so this can be a reason here. ok, i'll try the ebuild a little bit later.
Thanks for your work on this ebuild. I've submitted my version to science overlay, it doesn't offer so many features as yours i.e. only debug build. Though I'll work towards improving it :) BTW, you don't need to hack cmake.eclass. You can alter CMAKE_BUILD_TYPE variable prior running cmake-utils_src_configure
Why is this called "path64" instead of "ekopath"? It's confusing. We should probably have "path64" and "path64-bin", or "ekopath" and "ekopath-bin". But not "path64" and "ekopath-bin" :-/
(In reply to comment #13) > Why is this called "path64" instead of "ekopath"? It's confusing. We should > probably have "path64" and "path64-bin", or "ekopath" and "ekopath-bin". > > But not "path64" and "ekopath-bin" :-/ Ekopath is built and provided by PathScale, path64 can be built by anyone. They're both the same thing. Think of it as firefox/iceweasel in debian.
(In reply to comment #12) > BTW, you don't need to hack cmake.eclass. You can alter CMAKE_BUILD_TYPE > variable prior running cmake-utils_src_configure That's rather obvious, sorry. What I meant is that you can override the rest by using MYCMAKEARGS, e.g. export MYCMAKEARGS="-UCMAKE_USER_MAKE_RULES_OVERRIDE"
(In reply to comment #14) > (In reply to comment #13) > > Why is this called "path64" instead of "ekopath"? It's confusing. We should > > probably have "path64" and "path64-bin", or "ekopath" and "ekopath-bin". > > > > But not "path64" and "ekopath-bin" :-/ > > Ekopath is built and provided by PathScale, path64 can be built by anyone. > They're both the same thing. Think of it as firefox/iceweasel in debian. Then why call it "ekopath-bin" and not just "ekopath"? The "-bin" suffix suggests there's an "ekopath" that can be built from sources.
(In reply to comment #15) > (In reply to comment #12) > > BTW, you don't need to hack cmake.eclass. You can alter CMAKE_BUILD_TYPE > > variable prior running cmake-utils_src_configure I cannot use CMAKE_BUILD_TYPE because the gcc version can be build only with CMAKE_BUILD_TYPE=Debug and the ekopath/path64 version can be build only with CMAKE_BUILD_TYPE=Release (see the configure pathscale are providing). > That's rather obvious, sorry. What I meant is that you can override the rest by > using MYCMAKEARGS, e.g. > export MYCMAKEARGS="-UCMAKE_USER_MAKE_RULES_OVERRIDE" not sure I follow, when calling cmake, the eclass adds the override files after my MYCMAKEARGS, I wasn't able to prevent it. btw, if you find a way to force it to install to ekopath-${version} without failing compilation, please post it so I can fix the bug. Thanks.
(In reply to comment #16) > Then why call it "ekopath-bin" and not just "ekopath"? The "-bin" suffix > suggests there's an "ekopath" that can be built from sources. That's because I confused those matters myself at the beginning. Will fix that.
btw, in my currect version (the one I'm working on), I've disabled custom flags, it caused compilation to fail and according to pathscale's ceo, it isn't recommended and even not needed as the suite knows to do that by it self.
(In reply to comment #17) > (In reply to comment #15) > > (In reply to comment #12) > > > BTW, you don't need to hack cmake.eclass. You can alter CMAKE_BUILD_TYPE > > > variable prior running cmake-utils_src_configure > > I cannot use CMAKE_BUILD_TYPE because the gcc version can be build only with > CMAKE_BUILD_TYPE=Debug and the ekopath/path64 version can be build only with > CMAKE_BUILD_TYPE=Release (see the configure pathscale are providing). You can do: src_configure() { if use native ; then export CMAKE_BUILD_TYPE=Release else export CMAKE_BUILD_TYPE=Debug fi cmake-utils_src_configure } > > That's rather obvious, sorry. What I meant is that you can override the rest by > > using MYCMAKEARGS, e.g. > > export MYCMAKEARGS="-UCMAKE_USER_MAKE_RULES_OVERRIDE" > > not sure I follow, when calling cmake, the eclass adds the override files after > my MYCMAKEARGS, I wasn't able to prevent it. no. It adds after mycmakeargs (notice the case). You can do src_configure() { export MYCMAKEARGS="foo" mycmakeargs=(..) cmake-utils_src_configure } that will result in: cmake {gentoo_foo_1} {mycmakeargs} {gentoo_foo_2} {MYCMAKEARGS} see the eclass :)
(In reply to comment #20) > (In reply to comment #17) > > (In reply to comment #15) > > > (In reply to comment #12) > > > > BTW, you don't need to hack cmake.eclass. You can alter CMAKE_BUILD_TYPE > > > > variable prior running cmake-utils_src_configure > > > > I cannot use CMAKE_BUILD_TYPE because the gcc version can be build only with > > CMAKE_BUILD_TYPE=Debug and the ekopath/path64 version can be build only with > > CMAKE_BUILD_TYPE=Release (see the configure pathscale are providing). > > You can do: > src_configure() { > if use native ; then > export CMAKE_BUILD_TYPE=Release > else > export CMAKE_BUILD_TYPE=Debug > fi > cmake-utils_src_configure > } already doing it in the ebuild. > > > > That's rather obvious, sorry. What I meant is that you can override the rest by > > > using MYCMAKEARGS, e.g. > > > export MYCMAKEARGS="-UCMAKE_USER_MAKE_RULES_OVERRIDE" > > > > not sure I follow, when calling cmake, the eclass adds the override files after > > my MYCMAKEARGS, I wasn't able to prevent it. > > no. It adds after mycmakeargs (notice the case). You can do > src_configure() { > export MYCMAKEARGS="foo" > mycmakeargs=(..) > cmake-utils_src_configure > } > > that will result in: > > cmake {gentoo_foo_1} {mycmakeargs} {gentoo_foo_2} {MYCMAKEARGS} > > see the eclass :) thanks :) I'll modify the ebuild later today.
Created attachment 280479 [details] path64-suite-9999.ebuild, updated ebuild, no need to change cmakeutils. thanks to Xarthisius for the tip. I'm still working on the path change.
I'm helping xarthisius with the science overlay ebuild so this bug is closed.
(In reply to comment #23) > I'm helping xarthisius with the science overlay ebuild so this bug is closed. Not yet, we will close this bug when it hits portage :)
+*path64-1.0.0_pre20110729 (29 Jul 2011) + + 29 Jul 2011; Kacper Kowalik <xarthisius@gentoo.org> + +path64-1.0.0_pre20110729.ebuild, +metadata.xml: + Initial import, fixes bug 374739. Thanks to DaggyStyle + <stompdagger1@yahoo.com> for his work.
