Mantis Bugtracker

Einfache Problemansicht anzeigen Zu Notizen wechseln ] erweiterte Anzeige ] Problem-Historie ] Drucken ]
ID Kategorie Auswirkung Reproduzierbar Meldungsdatum Letzte Aktualisierung
0000112 [OCaml-Java] schwerer Fehler immer 2013-01-30 12:13 2013-03-07 23:14
Reporter chambart Anzeigestatus öffentlich  
Bearbeitung durch xclerc
Priorität normal Lösung erledigt  
Status geschlossen   Produktversion 2.0-early-access
Zusammenfassung 0000112: Hard coded stdlib path
Beschreibung ocamlc -where returns /ocamljava-2.0-early-access2/lib/ocaml.
This prevent almost all build system to work (particularily ocamlfind).

It should be possible to return somethings like argv.(0)/../lib
Zusätzliche Information
Tags Keine Tags zugeordnet.
Angehängte Dateien

- Problem-Beziehungen

-  Notiz
xclerc (Administrator)
2013-01-30 18:39

Well, the returned path is where the compiler actually looks
for file... in a jar archive though. And I am not a big fan of
relative paths in such cases.

Do you think that we can overcome the problem by having
a OCAMLJAVA_WHERE environment variable allowing to
override the actual value. I mean, your script probably use
ocamlc -where only to determine where to install files.
Is is right?
chambart (Reporter)
2013-01-30 19:00

I encoutered that when trying to build ocamlfind. I started
packaging ocamljava for opam and of course ocamlfind is the
first encountered package.

The idea of having ocamlc -where working is reduce the amout
of work needed to addapt classical toolchain to ocamljava.

This problem in fact does not comes from the changes in the compiler
but from the fact that is is distributed in binary form.

I would prefer a configuration file rather than an environment
variable. for instance, it should be possible to modify the shell
scripts such that they answer instead of ocaml.

I will provide a patch of the scripts for that.
chambart (Reporter)
2013-01-30 23:51

Adding something like

case $1 in
  -where*) echo `dirname $0`/../lib/; exit 0 ;;
  *) ;;

to common do the trick
xclerc (Administrator)
2013-02-01 16:54

Is it OK to have this patch applied only on OPAM side?
chambart (Reporter)
2013-02-01 19:51

It is reasonnable.
xclerc (Administrator)
2013-03-07 23:14

Then, I close this issue.

Any, this is a temporary situation, as problem
will be eventually solved by a source release.

- Problem-Historie
Änderungsdatum Benutzername Feld Änderung
2013-01-30 12:13 chambart Neues Problem
2013-01-30 18:39 xclerc Problemnotiz hinzugefügt: 0000265
2013-01-30 18:39 xclerc Bearbeitung durch => xclerc
2013-01-30 18:39 xclerc Status neu => Rückmeldung
2013-01-30 19:00 chambart Problemnotiz hinzugefügt: 0000266
2013-01-30 23:51 chambart Problemnotiz hinzugefügt: 0000268
2013-02-01 16:54 xclerc Problemnotiz hinzugefügt: 0000272
2013-02-01 19:51 chambart Problemnotiz hinzugefügt: 0000273
2013-03-07 23:14 xclerc Problemnotiz hinzugefügt: 0000274
2013-03-07 23:14 xclerc Status Rückmeldung => geschlossen
2013-03-07 23:14 xclerc Lösung offen => erledigt
2013-03-07 23:14 xclerc Behoben in Version => 2.0-early-access3

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker