Rosetta is used for prediction and design of protein structures, protein folding mechanisms, and protein-protein interactions. While there are online services around (see Robetta), this ebuild is the first step if one wants to run prediction tasks locally. The ebuild just provides the "rosetta" program itself. Ebuilds for database, antibody and documentation and scripts will follow separately, as these are very large packages. RDEPEND is not complete, as a variety of rosetta scripts needs packages, which are not already provided by gentoo. An example for this is ncbi-blast, another psipred. The ebuild is provided as a tar archive, as it contains a dozen patches.
Created attachment 174720 [details] Rosetta++ license
Created attachment 174722 [details] rosetta++ ebuild as a plain text file
Created attachment 174723 [details] rosetta++ metadata plain text
Created attachment 174724 [details] rosetta++ ChangeLog plain text
Created attachment 174726 [details] rosetta++ Manifest plain text
Created attachment 174727 [details] gzip compressed tar archive of rosetta ebuild directory, with patches
Does it compile with gcc-4*?
It could be named roseta++ as "+" is allowed. http://devmanual.gentoo.org/ebuild-writing/file-format/index.html
(In reply to comment #7) > Does it compile with gcc-4*? yes. I compiled it using 1.) gcc 4.2.4 (Gentoo Hardened 4.2.4-r1 p1.0, builtin ssp,fortify, pie-9.0.11) 2.) gcc-4.3.2 (Gentoo 4.3.2 p1.1)
Think http://depts.washington.edu/ventures/UW_Technology/Express_Licenses/rosetta.php is better in pkg_nofetch()
ncbi-blast is provided by sci-biology/ncbi-tools.
Can't you combine all those patches in one as-needed.patch?
typo in SRC_URI which leads to the speculation, that this ebuild was never used!?
icc 10.1 fails to build: KeyError: "Unknown version number 10.1 for compiler 'icc'" scons: done reading SConscript files. scons: Building targets ... scons: `.' is up to date. scons: done building targets. * * ERROR: sci-chemistry/rosetta-2.3.0 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2134: Called die * The specific snippet of code: * die "scons ${MYCONF} failed"; * The die message: * scons mode=release extras=graphics,mpi,valgrind cxx=icc failed PLUS CC=gcc and icc is used. That must be fixes.
(In reply to comment #13) > typo in SRC_URI which leads to the speculation, that this ebuild was never > used!? > No, the typo "rosetta++_srouce" is original, as you could have seen on the download page (after registration).
(In reply to comment #15) > (In reply to comment #13) > > typo in SRC_URI which leads to the speculation, that this ebuild was never > > used!? > > > No, the typo "rosetta++_srouce" is original, as you could have seen on the > download page (after registration). > Can not confirm, I saw https://www.rosettacommons.org/software/academic/2.3.0/rosetta++_source-2.3.0.tgz
(In reply to comment #14) > icc 10.1 fails to build: > > KeyError: "Unknown version number 10.1 for compiler 'icc'" > * The die message: > * scons mode=release extras=graphics,mpi,valgrind cxx=icc failed > > So you emerged rosetta with USE="opengl mpi icc" ? Please try USE="opengl mpi -icc". I haven't tried icc, but just provided the ability to use it, because icc is said to compile much faster code. > PLUS CC=gcc and icc is used. That must be fixes. > The maintainers of rosetta decided to switch to scons as the one and only supported build system. Hence I was forced to base this ebuild on scons too. Scons ignores each and everything what you are used from autoconf and gmake. I could test for $CC. But then I had to test $CXX to? To avoid such a mess, I introduced the icc - use flag, which is possibly not the best solution, though. > KeyError: "Unknown version number 10.1 for compiler 'icc'" While this really is an upstream problem, it should be easy to fix: look into tools/build/setup_platform.py and add support for icc 10.1 version, Then look into tools/build/options.settings. Just replace the line "icc" : [ "8.0", "8.1", "9.0", "9.1", "*" ], by "icc" : [ "8.0", "8.1", "9.0", "9.1", "10.1" *], and provide a patch, if you should succeed.
> So you emerged rosetta with USE="opengl mpi icc" ? Please try USE="opengl mpi > -icc". you are right. Sorry for that report. > The maintainers of rosetta decided to switch to scons as the one and only > supported build system. Hence I was forced to base this ebuild on scons too. there is a makefile included, therefor a make should work. I will try this. > Then look into tools/build/options.settings. Just replace the line > > "icc" : [ "8.0", "8.1", "9.0", "9.1", "*" ], > > by > > "icc" : [ "8.0", "8.1", "9.0", "9.1", "10.1" *], > > and provide a patch, if you should succeed. >
If MAKEOPTS="-j9 -l9" scons breaks as -l is not supported. SO this must be filtered.
The licence has to be in $PORTAGE_ROOT/licenses and not installed in src_install. do you use repoman?
(In reply to comment #16) >>> typo in SRC_URI which leads to the speculation, that this ebuild was never >>> used!? >>> >> No, the typo "rosetta++_srouce" is original, as you could have seen on the >> download page (after registration). > >Can not confirm, I saw >https://www.rosettacommons.org/software/academic/2.3.0/rosetta++_source-2.3.0.tgz > $ tar -tvzf RosettaBundle-2.3.0.tgz -rw-rw-r-- yiliu/yiliu 8007336 2008-04-18 22:42 rosetta++_srouce-2.3.0.tgz -rw-rw-r-- yiliu/yiliu 153930790 2008-04-18 22:44 rosetta_database-2.3.0.tgz -rw-rw-r-- yiliu/yiliu 3995023 2008-04-18 22:47 rosetta_documentation-2.3.0.tgz -rw-rw-r-- yiliu/yiliu 3822872 2008-04-18 22:52 rosetta_scripts-2.3.0.tgz -rw-rw-r-- yiliu/yiliu 91705267 2008-04-18 23:07 RosettaAntibody-2.3.0.tgz So there is a subtile inconsistency, depending on wha archive you download. I used RosettaBundle-2.3.0.tar.gz first, and later decided to rebase the ebuilds on the splitted archives, because a single combined ebuild would consume way too much disk space during build.
(In reply to comment #20) > The licence has to be in $PORTAGE_ROOT/licenses and not installed in > src_install. Then just how the a license usually arrives there? > do you use repoman? Yes.
(In reply to comment #22) > (In reply to comment #20) > > The licence has to be in $PORTAGE_ROOT/licenses and not installed in > > src_install. > If you create your personal overlay, just create an dir for that and place the license. Additionally add it to the bugreport and if it is added it will placed there by a dev. > Then just how the a license usually arrives there? > > > do you use repoman? > > Yes. > Then it should have been complaining about missing license.
Created attachment 174862 [details] revised ebuild - fix SRC_UL "source" vs "srouce" filename issue, add a warning - do not install license from src_install - do not pass insane MAKEOPTS -l and --load-average to scons
Created attachment 174863 [details] updated ChangeLog
Created attachment 174864 [details] updated Manifest
(In reply to comment #23) > Then it should have been complaining about missing license. It did. Did you get icc 10.1 compiling rosetta in the meantime?
>RDEPEND=" mpi? ( virtual/mpi ) This is a DEPEND as mpiCC is used for compilation. > boinc? ( sci-misc/boinc ) " > sys-apps/sed > sys-apps/findutils" Do we need to depend on @system packages at all? >src_prepare() { > > epatch "${FILESDIR}/rosetta-elliptic-msd.patch" > epatch "${FILESDIR}/rosetta-gl-graphics.patch" > epatch "${FILESDIR}/rosetta-setup-platforms.patch" > epatch "${FILESDIR}/rosetta-options-settings.patch" > epatch "${FILESDIR}/rosetta-FileName-cc-ostream.patch" > epatch "${FILESDIR}/rosetta-PathName-cc-ostream.patch" > epatch "${FILESDIR}/rosetta-basic-settings-nostdc99.patch" > epatch "${FILESDIR}/rosetta-SConscript-src-use-clone.patch" > epatch "${FILESDIR}/rosetta-SConscript-src-2-use-clone.patch" > epatch "${FILESDIR}/rosetta-string-functions-cc.patch" > epatch "${FILESDIR}/rosetta-zipstream-ipp.patch" > epatch "${FILESDIR}/rosetta-DirectedSimAnnealer-cc.patch" > epatch "${FILESDIR}/rosetta-dna-cc.patch" > epatch "${FILESDIR}/rosetta-kin_id-h.patch" > epatch "${FILESDIR}/rosetta-dna_classes-h.patch" > epatch "${FILESDIR}/rosetta-loop_class-h.patch" > epatch "${FILESDIR}/rosetta-barcode_classes-h.patch" > epatch "${FILESDIR}/rosetta-packing_measures-cc.patch" > epatch "${FILESDIR}/rosetta-XUtilities-cc.patch" > epatch "${FILESDIR}/rosetta-basic-settings-nostrip.patch" > epatch "${FILESDIR}/rosetta-basic-settings-gcc43.patch" > epatch "${FILESDIR}/rosetta-barcode_classes-h-unitialized.patch" > epatch "${FILESDIR}/rosetta-marchingCubes-cc-missing-braces.patch" Still would prefere to bundle some patches which are related e.g. patched headers, patched includes, patches for compiler stuff to end up with a small number. > >src_unpack() { > unpack ${A} >} This is default so you can leave this out (http://devmanual.gentoo.org/ebuild-writing/functions/index.html) >my_filter_option() { > local value="$1" > local exp="$2" > local result=`echo ${value} | sed -e s/${exp}//g` > echo "${result}" > return 0; >} Probably better to move you're functions to the end to enhance readability. >src_install() { > #install executable(s) > dobin bin/* Needs die. > if use doc; then > dohtml build/doc/rosetta++/docs/* > fi Probably you want to do it this way: use doc && dohtml build/doc/rosetta++/docs/* and some devs like to die here too.
(In reply to comment #27) > (In reply to comment #23) > > Then it should have been complaining about missing license. > It did. Did you get icc 10.1 compiling rosetta in the meantime? > No it couldn't find icpc, the cxx compiler of icc. Needs more testing.
(In reply to comment #28) > >RDEPEND=" mpi? ( virtual/mpi ) > This is a DEPEND as mpiCC is used for compilation. As for openmpi, it's probably both. > Do we need to depend on @system packages at all? Good question. The documentation says you have to include here all packages needed to compile the ebuild. Hence, you would have to include a compiler package too. And a shell, and a dozen very basic tools more? > Still would prefere to bundle some patches which are related e.g. patched > headers, patched includes, patches for compiler stuff to end up with a small > number. Sorry. Patches should be as small as possible. Crosspatching the whole system would make it difficult to bisect a problematic patch.
(In reply to comment #30) > Good question. The documentation says you have to include here all packages > needed to compile the ebuild. Hence, you would have to include a compiler > package too. And a shell, and a dozen very basic tools more? So no we don't need to depend on them. (http://devmanual.gentoo.org/general-concepts/dependencies/index.html) > > Still would prefere to bundle some patches which are related e.g. patched > > headers, patched includes, patches for compiler stuff to end up with a small > > number. > > Sorry. Patches should be as small as possible. Crosspatching the whole system > would make it difficult to bisect a problematic patch. > Quoting darkside: "a smaller amount of patches is preferred normally, use your discretion .... every file takes up 4K on unoptimized filesystems"
Created attachment 175093 [details] second revision of ebuild - Renamed ebuild from 'rosetta' to 'rosetta++' - Renamed ebuild directory, patches and license likewise - Removed explicit sys-apps/* dependencies from DEPEND - Removed rosetta license copy from files/static/rosetta - Commented each patch inside the patch itself - Combined several patches against barcode_classes.h into a single file - Removed patch against tools/build/basic.settings - Added patch against tools/build/user.settings and got icc working - Ebuild now compiles ok with: gcc 4.2.4-r1 p1.0, builtin ssp,fortify, pie-9.0.11 gcc 4.3.2 p1.1 icc 10.1.018 (Note: if you still get icpc not found see if libstdc++-v3 really is installed. icpc depends on this) - TODO: When using gcc 3.3.6-1, build still fails in dock_ensemble.cc:678, at a suspiciously looking construct (taking address of a temporary?). Same problem in dock_loop_ensemble.cc, pose_docking_flexible.cc. A similar problem exists in epigraft_functions.hh:59-61. Perhaps someone experienced with the ObjexxFCL fortran/c++ class library could fix this? - TODO: The boinc target still does not compile with any compiler, as does the test target, both to an invalid scons build setup. Don't know how to fix this.
Created attachment 175095 [details] updated Changelog
Created attachment 175098 [details] updated Manifest
Created attachment 175103 [details] Whole ebuild directory (contains updated patchset) Justin, could you please try to compile rosetta++ with icc now?
Comment on attachment 174720 [details] Rosetta++ license Please rename license file from "rosetta" to "rosetta++"
(In reply to comment #32) > Created an attachment (id=175093) [edit] > second revision of ebuild > > - Renamed ebuild from 'rosetta' to 'rosetta++' > - Renamed ebuild directory, patches and license likewise > - Removed explicit sys-apps/* dependencies from DEPEND > - Removed rosetta license copy from files/static/rosetta > - Commented each patch inside the patch itself > - Combined several patches against barcode_classes.h into a single file > - Removed patch against tools/build/basic.settings > - Added patch against tools/build/user.settings and got icc working > - Ebuild now compiles ok with: > gcc 4.2.4-r1 p1.0, builtin ssp,fortify, pie-9.0.11 > gcc 4.3.2 p1.1 > icc 10.1.018 (Note: if you still get icpc not found see if > libstdc++-v3 really is installed. icpc depends on this) > > - TODO: When using gcc 3.3.6-1, build still fails in dock_ensemble.cc:678, > at a suspiciously looking construct (taking address of a temporary?). > Same problem in dock_loop_ensemble.cc, pose_docking_flexible.cc. > A similar problem exists in epigraft_functions.hh:59-61. > Perhaps someone experienced with the ObjexxFCL fortran/c++ class > library could fix this? > - TODO: The boinc target still does not compile with any compiler, as does > the test target, both to an invalid scons build setup. Don't know how > to fix this. > Thanks for your enormous work on that . I'll go testing the weekend.
Tests are running: needs change in tools/build/basic.settings in line 407 - "cxx" : "mpiCC", + "cxx" : "mpicxx",
(In reply to comment #38) Looks like a bug in your local mpi version. Which mpi package are you using? I didn't see this with openmpi-1.2.8: $ ls -l /usr/bin/mpi* /usr/bin/mpic++ -> opal_wrapper /usr/bin/mpicc -> opal_wrapper /usr/bin/mpiCC -> opal_wrapper /usr/bin/mpicxx -> opal_wrapper [...]
I have currently mpich2 emerged: /usr/bin/mpicc /usr/bin/mpich2version /usr/bin/mpicxx /usr/bin/mpiexec /usr/bin/mpiexec.gforker /usr/bin/mpif77 /usr/bin/mpif90 /usr/bin/mpirun /usr/bin/mpirun.py /usr/bin/parkill So we need some correct. Perhaps we can find a package with similar situation.
And we need -fno-exeptions removed from settings: In file included from /usr/include/mpi.h:1143, from job_distributor.cc:12: /usr/include/mpicxx.h: In member function 'virtual void MPI::Datatype::Commit()': /usr/include/mpicxx.h:182: error: exception handling disabled, use -fexceptions to enable scons: *** [build/src/release/linux/2.6/32/x86/gcc/shared-graphics-mpi/rosetta++/job_distributor.o] Error 1 scons: building terminated because of errors.
(In reply to comment #41 and #42) > And we need -fno-exeptions removed from settings That's bad news. The maintainers had disabled exceptions for using them would result in a considerable runtime overhead. Can mpich2 be configured to compile without execeptions? Else it should dependend on mpich2. There is a inconsistency regarding used compiler too. openmpi just uses gcc, and AFAIK there is no possibility to integrate icc into gcc-config. As for mpiCC, mpicxx seems to be a common denominator. In addition, "man mpi" says that mpiCC only exists on systems with case sensitive file systems". Hence I'll add a patch.
(In reply to comment #42) > (In reply to comment #41 and #42) > > And we need -fno-exeptions removed from settings > That's bad news. The maintainers had disabled exceptions for using them would > result in a considerable runtime overhead. Can mpich2 be configured to compile > without execeptions? I don't know. We should figure this out. > Else it should dependend on mpich2. There is a > inconsistency regarding used compiler too. openmpi just uses gcc, and AFAIK > there is no possibility to integrate icc into gcc-config. There is a open bug for this. But I don't find him. > > As for mpiCC, mpicxx seems to be a common denominator. In addition, "man mpi" > says that mpiCC only exists on systems with case sensitive file systems". Hence > I'll add a patch. > I checked combination of USE="(-)mpi (-)icc" and all compile fine. So only two things to fix left: mpiCC and exceptions.
(In reply to comment #43) > I checked combination of USE="(-)mpi (-)icc" and all compile fine. > So only two things to fix left: mpiCC and exceptions. Having installed sys-cluster/mpich2-1.0.3-r1 instead of openmpi/1.2.8, I got the following mpi tools: ls -l /usr/bin/mpi* /usr/bin/mpicc /usr/bin/mpich2version /usr/bin/mpiexec -> mpiexec.py [...] Apparently, mpicxx is missing here because the use-flag "cxx" was not given during install. Some of the currently known mpi packages (mpich mpich2 mpiexec) do provide a "cxx" use flage, while some other (virtuals/mpi, openmpi and lam-mpi) do not. So, within an ebuild, how do you specifiy an additional use flags for packages listed in DEPEND ?
With EAPI="2" it is very straight, just DEPEND="foo/bar[cxx]". But I don't know if this is working with virtual/mpi[cxx]. I try to figure this out.
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manor. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Think this one makes more sense in the science overlay.