Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camlp4 -where dans le port Win32 natif #8295

Closed
vicuna opened this issue Sep 22, 2003 · 4 comments
Closed

camlp4 -where dans le port Win32 natif #8295

vicuna opened this issue Sep 22, 2003 · 4 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Sep 22, 2003

Original bug ID: 1846
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Après avoir telechargé et installé le package binaire OCaml 3.06 pour
Win32 natif, la commande "camlp4 -where" me donne:

C:/ocaml/lib/camlp4

alors que ça devrait être:

C:\Program Files\Objective Caml\lib\camlp4

ocamlc -where donne un résultat correct, et OCAMLLIB a la bonne valeur.

Est-ce un bug de la distribution?

Alain, qui commence à utiliser des plate-formes exotiques

@vicuna
Copy link
Author

vicuna commented Sep 25, 2003

Comment author: administrator

Known bug in 3.06. Fixed in 3.07. Xl, 2003-09-25

@vicuna vicuna closed this as completed Sep 25, 2003
@vicuna
Copy link
Author

vicuna commented Sep 26, 2003

Comment author: administrator

Salut Alain,

Voilà le code qui est exécuté par camlp4 -where:

try Sys.getenv "CAMLP4LIB" with Not_found ->
try Sys.getenv "OCAMLLIB" ^ "/camlp4" with Not_found ->
try Sys.getenv "CAMLLIB" ^ "/camlp4" with Not_found ->
"chemin créé lors de la configuration"

Ça fait en gros comme ocamlc, avec une variable d'env. en plus.

Dans ton cas, l'une des 2 dernières variables a probablement déjà une
valeur. Mettant CAMLP4LIB à la bonne valeur dans le .BAT qui va bien
devrait résoudre ton pb.

-- Michel

Alain.Frisch@ens.fr wrote/écrivait (Mon, Sep 22, 2003 at 04:13:08PM +0200):

Après avoir telechargé et installé le package binaire OCaml 3.06 pour
Win32 natif, la commande "camlp4 -where" me donne:

C:/ocaml/lib/camlp4

alors que ça devrait être:

C:\Program Files\Objective Caml\lib\camlp4

ocamlc -where donne un résultat correct, et OCAMLLIB a la bonne valeur.

Est-ce un bug de la distribution?

Alain, qui commence à utiliser des plate-formes exotiques

@vicuna
Copy link
Author

vicuna commented Sep 26, 2003

Comment author: administrator

On Fri, 26 Sep 2003, Michel Mauny wrote:

Voilà le code qui est exécuté par camlp4 -where:

try Sys.getenv "CAMLP4LIB" with Not_found ->
try Sys.getenv "OCAMLLIB" ^ "/camlp4" with Not_found ->
try Sys.getenv "CAMLLIB" ^ "/camlp4" with Not_found ->
"chemin créé lors de la configuration"

Ça fait en gros comme ocamlc, avec une variable d'env. en plus.

Dans ton cas, l'une des 2 dernières variables a probablement déjà une
valeur. Mettant CAMLP4LIB à la bonne valeur dans le .BAT qui va bien
devrait résoudre ton pb.

En effet, OCAMLLIB est défini, mais avec la bonne valeur:
C:\Program Files\Objective Caml\lib

CAMLP4LIB et CAMLLIB ne sont pas définis.

Dans ces condition, je ne comprends pas pourquoi camlp4 -where repond
C:/ocaml/lib/camlp4. J'ai regardé, ce chemin est dans le binaire (il ne
vaudrait pas mieux mettre un vrai chemin au moment de produire le binaire
pour Windows?). C'est comme si OCAMLLIB n'était pas trouvé dans
l'environnement...

En définissant CAMLP4LIB, je m'en sors.

-- Alain

@vicuna
Copy link
Author

vicuna commented Sep 26, 2003

Comment author: administrator

Alain.Frisch@ens.fr wrote/écrivait (Fri, Sep 26, 2003 at 04:26:13PM +0200):

En effet, OCAMLLIB est défini, mais avec la bonne valeur:
C:\Program Files\Objective Caml\lib

Oui, je n'avais pas réalisé que cela avait changé entre 3.06 et
maintenant: en 3.06, camlp4 ne regardait que CAMLP4LIB et ne testait
pas [O]CAMLLIB (va savoir pourquoi :-). Ça explique donc le
comportement.

Quant à câbler ou non le chemin en dur, c'est fait au moment de la
compilation (à peu près comme le fait ocamlc), et ça me semble
assez raisonnable.

-- Michel

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant