Summary: | dev-ml/pgocaml - a set of OCaml bindings for the PostgreSQL database | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jacques-Pascal Deplaix <jp.deplaix> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | ml |
Priority: | Normal | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://pgocaml.forge.ocamlcore.org/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 406659, 425078, 425088 | ||
Bug Blocks: | 437318 | ||
Attachments: |
pgocaml-1.6.ebuild
pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6.ebuild metadata.xml pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6-makefile.patch pgocaml-1.6-test.patch pgocaml-1.6.ebuild pgocaml-1.6.ebuild pgocaml-1.6-makefile.patch pgocaml-1.6-test.patch pgocaml-1.6-test.patch |
Created attachment 317794 [details]
pgocaml-1.6.ebuild
Created attachment 320068 [details]
pgocaml-1.6.ebuild
dev-ml/ocaml-csv => dev-ml/csv
> IUSE="batteries" please give me a metadata.xml <flag> entry to describe the useflag also, you dont seem to use the useflag anywhere in the ebuild > echo "DESTDIR := \"${D}/\"" >> Makefile.config use ED instead of D > src_configure() { > emake depend || die > emake || die > } there is a make doc target it seems > src_install() { > emake install || die > } missing dodoc for the relevant *.txt files tests fail here (both USE=+/-batteries): >>> Test phase [test]: dev-ml/pgocaml-1.6 ocamlfind ocamlc -g -syntax camlp4o -package camlp4.macro -package unix,extlib,pcre,calendar,csv -c test_pgocaml_lowlevel.ml ocamlfind ocamlc -g -package unix,extlib,pcre,calendar,csv -linkpkg pgocaml.cma -o test_pgocaml_lowlevel test_pgocaml_lowlevel.cmo ocamlfind ocamlc -g -package unix,extlib,pcre,calendar,csv -linkpkg -pp "camlp4o -I +unix /usr/lib64/ocaml/unix.cma -I +str /usr/lib64/ocaml/str.cma -I +pcre /usr/lib64/ocaml/pcre/pcre.cma -I +extlib /usr/lib64/ocaml/extlib/extLib.cma -I +calendar /usr/lib64/ocaml/calendar/calendarLib.cma -I +csv /usr/lib64/ocaml/csv/csv.cma ./pgocaml.cma ./pa_pgsql.cmo" -c test_pgocaml.ml File "test_pgocaml.ml", line 27, characters 23-168 (end at line 32, character 4): Camlp4: Uncaught exception: Unix.Unix_error (20 | CstTag21, "connect", "") File "test_pgocaml.ml", line 1, characters 0-1: Error: Preprocessor error make: *** [test_pgocaml.cmo] Error 2 Created attachment 320072 [details]
pgocaml-1.6.ebuild
Fixed. Please notice that you can't do "make test" because the specificity of pgocaml is to do the sql type checking at compile-time.
So, pgocaml want a open connection to the sql server (in this case: postresql).
Created attachment 320074 [details]
metadata.xml
Created attachment 320078 [details]
pgocaml-1.6.ebuild
Little fix on doc installation.
> dodoc BUGS.txt CONTRIBUTORS.txt HOW_IT_WORKS.txt README.txt \ CHANGELOG.txt COPYING.LIB README.profiling these should be installed regardless of USE=doc COPYING is not needed > src_configure() { > emake depend || die > if use doc; then > emake doc || die > fi > emake || die >} you dont need || die for emake in EAPI 4 and this is for src_compile, not src_configure tests should be restricted, or a sql server should be started in the test process if we want this to work then > src_prepare() { > echo "DESTDIR := \"${ED}/\"" >> Makefile.config > if use batteries; then > echo "USE_BATTERIES := yes" >> Makefile.config > fi > } this is rather src_configure stuff > <flag name='batteries'>Enable Batteries support instead of extlib</flag> description could be improved imho I guess a newcomer will ask: - what do i gain with batteries instead of extlib ? - wtf is batteries or extlib ? Created attachment 320092 [details]
pgocaml-1.6.ebuild
(In reply to comment #7) > tests should be restricted, or a sql server should be started in the test > process if we want this to work then I don't counsel you to do that. This will cause a lot of installation problemes. (In reply to comment #9) > (In reply to comment #7) > > tests should be restricted, or a sql server should be started in the test > > process if we want this to work then > > I don't counsel you to do that. This will cause a lot of installation > problemes. I dont understand your comment :( restricting tests must not hurt; starting a postgres server locally so that the tests can proceed shouldnt hurt either, right ? or did I miss something ? (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > tests should be restricted, or a sql server should be started in the test > > > process if we want this to work then > > > > I don't counsel you to do that. This will cause a lot of installation > > problemes. > > I dont understand your comment :( > restricting tests must not hurt; starting a postgres server locally so that > the tests can proceed shouldnt hurt either, right ? or did I miss something ? Hmm, we must create a postgres user before, delete it after, pray for the user did not put a password on the user postgres, pray for dosens of other restrictions that the user can put. It's realy not a good idea. Trust me on that point. :( (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #7) > > > > tests should be restricted, or a sql server should be started in the test > > > > process if we want this to work then > > > > > > I don't counsel you to do that. This will cause a lot of installation > > > problemes. > > > > I dont understand your comment :( > > restricting tests must not hurt; starting a postgres server locally so that > > the tests can proceed shouldnt hurt either, right ? or did I miss something ? > > Hmm, we must create a postgres user before, delete it after, pray for the > user did not put a password on the user postgres, pray for dosens of other > restrictions that the user can put. why ? cant we just run the postgres server within the test phase with whatever user the build/tests are performed ? (In reply to comment #12) > why ? cant we just run the postgres server within the test phase with > whatever user the build/tests are performed ? No, we have to create the corresponding sql user before. (In reply to comment #13) > (In reply to comment #12) > > why ? cant we just run the postgres server within the test phase with > > whatever user the build/tests are performed ? > > No, we have to create the corresponding sql user before. because of postgres or pgocaml ? im pretty sure a postgresql server can be run by any user (In reply to comment #14) > because of postgres or pgocaml ? > im pretty sure a postgresql server can be run by any user Because of postgres. As far as I know, it's not possible without creating the corresponding sql user, or use an already created user (which have maybe a password). Why do you want your tests so much ? (In reply to comment #15) > Why do you want your tests so much ? because your ebuild doesnt restrict them :) and anyway, its always better to have some tests than nothing at all (In reply to comment #17) > and anyway, its always better to have some tests than nothing at all Yes, but not in this case ;) (In reply to comment #18) > (In reply to comment #17) > > and anyway, its always better to have some tests than nothing at all > > Yes, but not in this case ;) Or, you can look at how it's handled in dev-libs/libpqxx and use that. (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > and anyway, its always better to have some tests than nothing at all > > > > Yes, but not in this case ;) > > Or, you can look at how it's handled in dev-libs/libpqxx and use that. OK. "tests" or how complicate things for nothing... GREAT ! :( Anyway, Ok, I'll do that because you seems to hold. But, can you handle eliom and ocsigenserver first ? :) Created attachment 320788 [details]
pgocaml-1.6.ebuild
With src_test :)
Created attachment 320790 [details]
pgocaml-1.6.ebuild
Without the postgresql-server depend (can be remote)
Is it good now ? Ping. Alexis ? Somebody ? seems good thanks, though with USE=batteries, tests fail: make -j6 test ocamlfind ocamlc -g -syntax camlp4o -package camlp4.macro -ppopt -DUSE_BATTERIES -package unix,batteries,pcre,calendar,csv -c test_pgocaml_lowlevel.ml ocamlfind ocamlc -g -package unix,batteries,pcre,calendar,csv -linkpkg -pp "camlp4o -I +unix /usr/lib64/ocaml/unix.cma -I +str /usr/lib64/ocaml/str.cma -I +pcre /usr/lib64/ocaml/pcre/pcre.cma -I +batteries /usr/lib64/ocaml/batteries/batteries_uni.cma -I +calendar /usr/lib64/ocaml/calendar/calendarLib.cma -I +csv /usr/lib64/ocaml/csv/csv.cma ./pgocaml.cma ./pa_pgsql.cmo" -c test_pgocaml.ml Camlp4: Uncaught exception: DynLoader.Error ("/usr/lib64/ocaml/batteries/batteries_uni.cma", "error while linking /usr/lib64/ocaml/batteries/batteries_uni.cma.\nReference to undefined global `Big_int'") File "test_pgocaml.ml", line 1, characters 0-1: Error: Preprocessor error make: *** [test_pgocaml.cmo] Error 2 make: *** Waiting for unfinished jobs.... File "test_pgocaml_lowlevel.ml", line 25, characters 0-12: Error: Unbound module ExtList make: *** [test_pgocaml_lowlevel.cmo] Error 2 Created attachment 323408 [details]
pgocaml-1.6.ebuild
Fixed
Created attachment 323410 [details]
pgocaml-1.6-makefile.patch
Created attachment 323412 [details]
pgocaml-1.6-test.patch
do these patches come from upstream ? could you please add some info at the top of the patch so that they can be tracked ? Created attachment 323810 [details]
pgocaml-1.6.ebuild
No, these patchs don't come from upstream.
But, I'm doing it right now. :)
(In reply to comment #30) > Created attachment 323810 [details] > pgocaml-1.6.ebuild > > No, these patchs don't come from upstream. > But, I'm doing it right now. :) thanks, though i meant a description in the patch header, its not very important to have it in the ebuild see e.g.: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/ocaml/4.00.0/020_all_configure.patch?revision=1.1&view=markup Created attachment 323864 [details]
pgocaml-1.6.ebuild
Created attachment 323866 [details, diff]
pgocaml-1.6-makefile.patch
Created attachment 323868 [details, diff]
pgocaml-1.6-test.patch
not sure what went wrong but it seems the patches broke the tests even more: * Define them at the command line or in: * /etc/pgocaml_test_env * PGUSER set to: postgres * PGHOST set to: localhost * PGPORT set to: make -j6 test ocamlfind ocamlc -g -syntax camlp4o -package camlp4.macro -package unix,extlib,pcre,calendar,csv -c test_pgocaml_lowlevel.ml ocamlfind ocamlc -g -package unix,extlib,pcre,calendar,csv -linkpkg -pp "camlp4o -I +unix /usr/lib64/ocaml/unix.cma -I +str /usr/lib64/ocaml/str.cma -I +num.core /usr/lib64/ocaml/nums.cma -I +bigarray /usr/lib64/ocaml/bigarray.cma -I +pcre /usr/lib64/ocaml/pcre/pcre.cma /usr/lib64/ocaml/extlib/extLib.cma -I +calendar /usr/lib64/ocaml/calendar/calendarLib.cma -I +csv /usr/lib64/ocaml/csv/csv.cma ./pgocaml.cma ./pa_pgsql.cmo" -c test_pgocaml.ml File "test_pgocaml_lowlevel.ml", line 33, characters 2-12: Error: Unbound value List.iteri make: *** [test_pgocaml_lowlevel.cmo] Error 2 make: *** Waiting for unfinished jobs.... * ERROR: dev-ml/pgocaml-1.6 failed (test phase): * emake failed * Created attachment 323896 [details, diff]
pgocaml-1.6-test.patch
Oh I'm sorry, I had tested it with ocaml-4.00.0.
finally added, thanks :) |
Created attachment 317456 [details] pgocaml-1.6.ebuild PG'OCaml is a set of OCaml bindings for the PostgreSQL database.