"EUHEDRAL was developed for the refinement of the crystal shape against the intensities of multiple measured reflections coming from redundant area detector data." Another sci-* (crystallography) application, which sadly references files and docs from the binary workfolder. The best solution would be to dive into the fortran source and patch it to be conform with fhs. But I do not feel able to do this, this ebuild installs the application into /opt, even thou it is not bin-only. PS: I tried my best to please repoman.
Created attachment 89715 [details] euhedral-20060621.ebuild
Created attachment 89716 [details, diff] select-cc.patch
Created attachment 89720 [details] euhedral-20060621.ebuild (with fetch restrictions) Added fetch restrictions and help for the user as upstream does not supply versioned tar balls.
Created attachment 89819 [details, diff] euhedral-1.3.diff a diff to cleanup the ebuild somewhat Hi Jan. I somewhat cleaned-up an ebuild - made it really use fortran.eclass (you inherited it, but what was actually using it?) and made it prepare Makefile via sed instead of patch (so that it can pick up proper CFLAGS. It should also be able to use other fortran compilers as well, but this I left out so far..). Also, the fetch restrictions are unnecessary, as the source will have to be simply given a proper name and mirrored (so, don't pay much attention to the single line left in pkg_nofetch - I left it as a reminder to do this source renaming). Best of all, upstream should be hit hard with a cluestick :), but I am not sure this will be very usefull, looking at how the last release was in Jan 2004. Is the package still maintained upstream? If not, you will have to assume its maintainership (not just the ebuild, the package itself), if you want it in the tree ;). BTW, the version should probably be 1.3, not the datestamp (this is the last release reported on the site). However all in all it fails to build on me. This is the tail (first it spits many complaints about obsolete real DO loop): g77 -O2 -DUNIX -c libccd.f g77 -O2 -DUNIX -c libwin.f g77 -O2 -DUNIX -c librtl.f In file librtl.f:40 pause 'Type CONTINUE to accept 0 as result or EXIT to abort' 1 Warning: Obsolete: PAUSE statement at (1) gcc -DPOSIX -DUNIX -O2 -c libc.c gcc -DPOSIX -DUNIX -O2 -c winx.c rm -f euhedral g77 -O2 -DUNIX euhedral.o libccd.o libwin.o librtl.o libc.o winx.o -lX11 -o euhedral librtl.o: In function `today_': librtl.f:(.text+0x23f9): undefined reference to `date_' librtl.o: In function `spawncc_': librtl.f:(.text+0x69d2): undefined reference to `system_' librtl.o: In function `spawn_': librtl.f:(.text+0x6b72): undefined reference to `system_' collect2: ld returned 1 exit status This might be related to me trying to build it on amd64, but I doubt that - the error messages are about some symbols missing. Looks like some lib or somebodie's rtl is not getting linked into it.. (and this is not due to --as-needed, nothing suggests so and I just tried disabling it to no avail..) Can you comment on this failure? George
A short update - it compiles with gcc-3.4.6, so this is apparently the (rather usual) case of "bad" code (using non-standard/deprecated features).. I am afraid upstream has to fix the code before this can be considered for inclusion.. As I mentioned in our irc chat - looks like a better place for this package may be in overlay, if there is a substantial interest in it at all.. George
(In reply to comment #5) > A short update - it compiles with gcc-3.4.6, so this is apparently the > (rather usual) case of "bad" code (using non-standard/deprecated features).. > I am afraid upstream has to fix the code before this can be considered for > inclusion.. I contacted upstream explaining the issues and am awaiting a response now. > looks like a better place for this package may be in overlay I agree on this.
You can look at platon ebuild and see how it works around this issue by using libf2c on non-g77 cases.
Created attachment 91441 [details] euhedral-1.4.ebuild Upstream is now releasing versioned archives and fixed the source for gfortran of gcc4.1. Therefore I removed fetch restrictions. Sadly upstream is not willing to change the directory layout: "We understand the proposal from FHS, but we did not change our directory structure. We want to keep all files (binary, documentation, configuration) in one directory tree. This way the installation (a simple 'cp') and de-installation (a simple 'rm -r') is straightforward. There is no need for a configuration script and the program itself needs no further installation information. (This all is similar to programs as AcrobatReader, Mathematica and crystallographic packages as CCP4 and phenix)" So I'm still installing this package into /opt.
Hi Jan. First of all, thanks a lot for taking this up with the upstream! (In reply to comment #8) > Upstream is now releasing versioned archives and fixed the source for gfortran > of gcc4.1. Therefore I removed fetch restrictions. Nice! > Sadly upstream is not willing to change the directory layout: [skipped] > So I'm still installing this package into /opt. Still it should go under /usr/lib, even as a single dir (so it would become /usr/lib/${PN}) (+ you can put the docs (except the ones referenced in the code) where proper and provide symlinks to binaries under /usr/bin if that works) but still under /usr/lib. /opt is for stuff that was built upstream and on which we do minimal manipulations. 1. This is anyway more FHS compliant (this situation is covered by one of the clauses, even if not completely directly IIRC) 2. Gentoo specific: prebuilt binaries are treated differently from what gets built locally and portage expects to handle prebuilt binaries upder /opt and do all the "regular" treatment (stripping, prelinking, etc) to anything under /usr George
Ok, changing this in the ebuild is sufficient: src_install() { # Euhedral is looking for docs and special files + # at the location of its binary. Putting it all + # in /usr/lib seems to be the cleanest solution. + MY_D=/usr/lib/${P} ... I can confirm it working and opening the manual with firefox here. Could you test, if it's really working with gcc 4.1?
Note that with one of those examples, CCP4, we (I) did hack it up to install properly to normal locations.
Current version is 1.6
Actually, I think I should reassign it, to reflect where it belongs. Sorry about sitting on it, although sci-chemistry was on CC allo along.
