ocamlgraph in portage is really outdated and a 1.1 version has been released just recently: http://ocamlgraph.lri.fr/download/ocamlgraph-1.1.tar.gz
Created attachment 197868 [details] dev-ml/ocamlgraph/ocamlgraph-1.1.ebuild Here is a suggested ebuild.
Created attachment 197870 [details, diff] dev-ml/ocamlgraph/files/ocamlgraph-1.1-makefile_sandbox.patch This patch fixes the sandbox violation problem that occurs during the installation process.
Created attachment 198211 [details] dev-ml/ocamlgraph/ocamlgraph-1.1.ebuild Updated ebuild.
Created attachment 198213 [details, diff] dev-ml/ocamlgraph/files/ocamlgraph-1.1-makefile.patch Also fixes ocamlopt linking.
Created attachment 208070 [details] dev-ml/ocamlgraph/ocamlgraph-1.2.ebuild version bump
Created attachment 208071 [details, diff] dev-ml/ocamlgraph/files/ocamlgraph-1.2-makefile.patch version bump
Created attachment 208073 [details] dev-ml/ocamlgraph/ocamlgraph-1.2.ebuild eapi2 update
summary update
Created attachment 208098 [details] dev-ml/ocamlgraph/ocamlgraph-1.2.ebuild eapi2 update
Please use repomen and ChangeLog also in overlays. What does the gtk use is good for? Does it automacigally build gtk support? Why did you change so drastically the style of the ebuild compared to the in tree ebuild?
"Please use repomen and ChangeLog also in overlays." Done. "What does the gtk use is good for? Does it automacigally build gtk support?" Now the makefile builds the graphviewer by default if gtk is present. I'll modify the ebuild so that's disabled even if gtk is present when the use flag is not enabled. "Why did you change so drastically the style of the ebuild compared to one the in tree ebuild?" Because the ebuild in the portage tree is several years old, seven version bumps since then, plus a few cleanups. ocamlgraph-1.5 is now in the sci overlay
(In reply to comment #11) > "Why did you change so drastically the style of the ebuild compared to one the > in tree ebuild?" > Because the ebuild in the portage tree is several years old, seven version > bumps since then, plus a few cleanups. For what I see from what is attached here, the ocamlopt useflag seems to be automagic; I wouldn't call that a cleanup and it has nothing to do with the number of versions we are lagging behind :) Anyway, I don't know what is in the sci overlay but if you want to see it bumped in the main tree please attach the ebuild here so that it can be reviewed.
> Anyway, I don't know what is in the sci overlay but if you want to > see it bumped in the main tree please attach the ebuild here > so that it can be reviewed. Will do, but maybe I'll try to improve it a bit before. > For what I see from what is attached here, > the ocamlopt useflag seems to be automagic; What's wrong with the ocamlopt useflag ? If you want to build ocamlgraph with with ocamlopt, then dev-lang/ocaml should have been built with this flag as well. Isn't that the proper way to code this ?
> I'll modify the ebuild so that's disabled > even if gtk is present when the use flag is not enabled. Well it seems the configure script does not offer such an option, so here is the latest ebuild from the sci overlay
Created attachment 237751 [details] dev-ml/ocamlgraph/ocamlgraph-1.5.ebuild
Created attachment 237753 [details, diff] dev-ml/ocamlgraph/files/ocamlgraph-1.5-makefile.patch
(In reply to comment #13) > > For what I see from what is attached here, > > the ocamlopt useflag seems to be automagic; > What's wrong with the ocamlopt useflag ? If you want to build ocamlgraph with > with ocamlopt, then dev-lang/ocaml should have been built with this flag as > well. Isn't that the proper way to code this ? > yes but that's only half of it; if I have ocaml built with ocamlopt and build ocamlgraph without ocamlopt then I dont want native code in ocamlgraph which doesn't seem honoured from your ebuild
That's true, but am I wrong or the ebuild in portage does have the same problem ?
1.8.5 is in tree
