0001687: load_path

Notes
(0000154) administrator (administrator) 2003-05-12 20:10	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.

(0000155) administrator (administrator) 2003-05-14 18:21	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

(0000156) administrator (administrator) 2003-05-15 15:13	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.

(0000157) administrator (administrator) 2003-07-07 11:31	Bruno's problem was solved in another way. What to do with -I- remains unclear.

(0006814) doligez (manager) 2012-01-26 23:07	We are not working on this feature, but if someone comes up with a patch to implement -I-, we will consider applying it.

Issue History
Date Modified	Username	Field	Change
2005-11-18 10:13	administrator	New Issue
2012-01-26 23:07	doligez	Note Added: 0006814
2012-01-26 23:07	doligez	Status	acknowledged => resolved
2012-01-26 23:07	doligez	Resolution	open => suspended
2012-01-26 23:07	doligez	Description Updated	View Revisions

Relationships