This is an ebuild I made about a year ago, based off of a FreeBSD ports package. It's been kicking around in my /usr/local/portage for long enough. This is very simple, and just installs the cryptokit library for Objective Caml. Let me know how it works! Cheers, Jeff
Created attachment 99828 [details] ocaml-cryptokit-1.3.ebuild
Some remarks on your ebuild: - we try to avoid as much as possible using executables like sed or cut in global scope (here in SRC_P). In this case, it would be better to use the versionator eclass. - there is no need for the SRC_A variable, it would be more clear to add the ".tar.gz" suffix directly in SRC_URI. - the declaration of S should be quoted. - why do you test for makeopt like this, and fail if it doesn't exist? If for some obscure reason it isn't installed anymore, the Makefile will die nicely, so 'emake allopt || die "make allopt failed"' is a much shorter way to write the same thing. - the einfo should go either in pkg_preinst or pkg_postinst. - I think the message in einfo is unclear. If it is required, it means that the software will fail without it... - Is the stuff in src_install with `ocamlc -g -where` really needed? If yes, a better option would be to fix the Makefile itself and have a standard "make DESTDIR="${D}" install" - we do not install the LICENSE files, as they are already in /usr/portage/licence. Please provide an updated ebuild and I'll probably add it to the tree.
Thank you for the feedback. Two responses though, starting with this comment: > - why do you test for makeopt like this, and fail if it doesn't exist? If for > some obscure reason it isn't installed anymore, the Makefile will die nicely, > so 'emake allopt || die "make allopt failed"' is a much shorter way to write > the same thing. I'm not testing for makeopt, but for the presence of the ocamlopt executable. Here is what the README for cryptokit says: - If the Objective Caml native-code compiler is available on your platform (look for the "ocamlopt" executable), do "make allopt". Secondly: > - Is the stuff in src_install with `ocamlc -g -where` really needed? If yes, a > better option would be to fix the Makefile itself and have a standard "make > DESTDIR="${D}" install" The problem here is that the Makefile calculates INSTALLDIR=`ocamlc -g -where` as the install path. However, this needs to be prefixed with ${D}, which is why I overrode it in the ebuild. I'd rather not start tinkering with the Makefile since I am not the maintainer of the library, but if you know of a better way to do this I'll fix it. By the way, I renamed the ebuild to just 'cryptokit' since that's really what the name of it is, rather than ocaml-cryptokit (plus it means the 'ocaml-' part doesn't have to be stripped off for the SRC_URI...but if it did is there an eclass like versionator that can chop up the ${PN} var?). Once I hear back on these few things I'll upload the latest. Thanks, Jeff
My bad, I meant "test for ocamlopt", not "test for makeopt". My point being that as cryptokit depends on dev-lang/ocaml, which installs ocamlopt, it's not the ebuild job to test whether it exists or not, as it *will* exist unless the system is seriously broken or root did "rm /usr/bin/ocamlopt"... As for remark 2, Makefiles generally have some PREFIX variable that is used for this kind of things. We generally prefer patching build systems to exhibit a sane behaviour, rather than having ugly workarounds in the ebuild itself. If you don't see any easy way to fix this one, then we can consider keeping the `ocamlc -g -where` but I'd really rather not. The fact that neither you nor I is upstream shouldn't matter, as it's the distribution job to patch packages so that they can be installed correctly. 'cryptokit' also seems better to me, as 'dev-ml/ocaml-cryptokit' is a bit redundant. versionator.eclass can not manage such changes but there wouldn't be much point in trying to be generic, since the name of the ebuild is not expected to change, so a simple MY_PN="cryptokit" would be enough. In case such replacements are needed, bash syntax ${PN/ocaml-/} would be preferred.
So if I write a patch for the Makefile and include that with the ebuild will it suffice? (In reply to comment #4) > As for remark 2, Makefiles generally have some PREFIX variable that is used for > this kind of things. We generally prefer patching build systems to exhibit a > sane behaviour, rather than having ugly workarounds in the ebuild itself. If > you don't see any easy way to fix this one, then we can consider keeping the > `ocamlc -g -where` but I'd really rather not. The fact that neither you nor I > is upstream shouldn't matter, as it's the distribution job to patch packages so > that they can be installed correctly.
Yes, you need to add it to the files/ directory. Then you can apply it using epatch, provided by the eutils eclass, during src_unpack.
Created attachment 113433 [details, diff] cryptokit-1.3-gentoo.patch This is a patch to fix the Makefile for gentoo installs.
Created attachment 113434 [details] cryptokit-1.3.ebuild
I've finally gotten around to fixing the ebuild and creating a Makefile patch for this package. Please have a look and test it out, thanks!
*** Bug 198468 has been marked as a duplicate of this bug. ***
Created attachment 135564 [details] cryptokit-1.3.ebuild Sorry for the duplicate. Here is a revised version of the ebuild above which installs the library via ocamlfind, rather than just copying files. It is cleaner, and ensures the package is found with "ocamlfind query cryptokit", which is needed by the compile process of www-servers/ocsigen-0.99.3 .
Created attachment 135565 [details, diff] cryptokit-gentoo.patch Matching version of the patch to the Makefile.
Created attachment 135567 [details] META META file for "ocamlfind install"
added, thanks
