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

load_path #8146

Closed
vicuna opened this issue May 12, 2003 · 5 comments
Closed

load_path #8146

vicuna opened this issue May 12, 2003 · 5 comments

Comments

@vicuna
Copy link

vicuna commented May 12, 2003

Original bug ID: 1687
Reporter: administrator
Status: closed (set by @xavierleroy on 2013-08-31T10:46:12Z)
Resolution: suspended
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Est-il bien nécessaire de mettre implicitement le directory courant dans
load_path ? Dans toploop.ml, il y a
let set_paths () =
(* Add whatever -I options have been specified on the command line,
but keep the directories that user code linked in with ocamlmktop
may have added to load_path. *)
load_path := !load_path @ [Filename.concat Config.standard_library "camlp4"];
load_path := "" :: (List.rev !Clflags.include_dirs @ !load_path);

Voici ce qui m'arrive: j'ai un script, exécuté par un top-level a été fait
avec une 3.06. qui commence par:
#load "cstr.cma";
Et ce script ne fonctionne pas dans un directory qui contient un cstr.cma
dont je ne veux pas (compilé avec une version CVS de Caml...).

S'il y a un contre-exemple qui justifie . dans load_path, je suppose que je
n'ai plus qu'à l'enlever à la main en m'initialisant ? Ou alors le top-level
n'ajoute . que s'il est interactif ?

Bruno.

@vicuna
Copy link
Author

vicuna commented May 12, 2003

Comment author: administrator

En fait, je me demande si j'ai bien localisé l'origine du problème, parce
que dans un directory ne contenant pas mon .cma, les syscalls sont les
suivants:
stat64("cstr.cma", 0xbfffed58) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", {st_mode=S_IFREG|0644, st_size=309344, ...}) = 0
open("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", O_RDONLY|O_LARGEFILE) = 5

Or contrib est ajouté par -I, et se trouve donc avant "" dans le load_path.
Donc le choix d'essayer . est peut-être ailleurs.

Bruno.

@vicuna
Copy link
Author

vicuna commented May 14, 2003

Comment author: administrator

From: Bruno.Verlyck@inria.fr

En fait, je me demande si j'ai bien localisé l'origine du problème, parce
que dans un directory ne contenant pas mon .cma, les syscalls sont les
suivants:
stat64("cstr.cma", 0xbfffed58) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", {st_mode=S_IFREG|0644, st_size=309344, ...}) = 0
open("/usr/local/lib/ocaml-3.06/contrib/cstr.cma", O_RDONLY|O_LARGEFILE) = 5

Or contrib est ajouté par -I, et se trouve donc avant "" dans le load_path.
Donc le choix d'essayer . est peut-être ailleurs.

Non, c'est bien le comportement normal d'ocaml: "." est toujours mis
en tete du load-path, meme en presence de -I, parce que c'est un
comportement souhaitable lors de la compilation.

Ce probleme me semble specifique aux scripts. Peut-etre faut-il un
flag special pour vider le path. Il me semble avoir vu -I- suggere'
quelque part. Ca serait plutot rigolo:

    ocaml -I- -I + -I +contrib

le "-I +" etant pour la librairie standard...

Jacques

@vicuna
Copy link
Author

vicuna commented May 15, 2003

Comment author: administrator

From: Pierre Weis pierre.weis@inria.fr
Date: Thu, 15 May 2003 12:39:33 +0200 (MET DST)

Ce qui est fait actuellement: dans le toplevel comme dans les compilos, le
load path contient:

  • le répertoire courant (toujours présent, toujours en tête)
  • les répertoires donnés par -I
  • la librarie standard.
    Maintenant, on peut discuter de plein de choses, e.g.
    Ok, discutons.
  • le répertoire courant doit-il toujours être en tête dans le path?
  • faut-il une option pour l'enlever? (cf. l'option -I- de gcc)
  • etc.
    J'avoue ne pas avoir d'idées arrêtées, sauf que il vaudrait beaucoup mieux
    rester compatible par défaut avec le comportement actuel.

L'option -I- me semble respecter toutes les contraintes et devrait donc
satisfaire tout le monde sans poser de problème à quiconque.
Pour mon usage personnel, ça suffit en effet. Pour Cash, comme il est
possible de passer des options au toplevel, je peux documenter. Mais pour
ceux qui font des scripts avec un toplevel standard, on retombe sur le
problème de troncature de la ligne #! : s'il faut passer
-I- -I + -I +contrib
après #!path en 32 caractères, ça marche moins bien. En fait ça n'a pas
d'importance; il suffit d'utiliser #directory à la place de -I, si ça fait
bien la même chose. -I appelle Dll.add_path comme #directory ? Ah, par
contre, il faudrait une directive pour faire -I- interactivement (pas
#directory seul, svp).

Je ne vois pas dans quelle circonstance on voudrait supprimer la librairie
standard; ça ne peut être que pour la remplacer par une autre pour faire bus
error, non ? Alors -I- devrait laisser -I + ?

Pourquoi laisser le directory courant ? Je pensais que c'était pour le bus
error aussi :-), mais c'est incompatible avec un toplevel interactif; je
suis bien d'accord de ne pas changer le comportement de ce dernier, mais
dans un script, ça devient franchement douteux. Bref, pas d'idée.

Tout ceci concernait les scripts, mais dans un toplevel interactif, on ne
sait pas toujours où on en est. 2 feature wishes: ce serait bien que
#directory sans argument donne la liste courante. #undirectory (:-), i.e.
un moyen d'enlever quelque chose de load_path, ça pourrait être utile aussi.

Bruno.

@vicuna
Copy link
Author

vicuna commented Jul 7, 2003

Comment author: administrator

Bruno's problem was solved in another way. What to do with -I- remains unclear.

@vicuna
Copy link
Author

vicuna commented Jan 26, 2012

Comment author: @damiendoligez

We are not working on this feature, but if someone comes up with a patch to implement -I-, we will consider applying it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant