<gnech>
it says "T:\Program Files (x86)\OCaml\lib"
<thelema>
ok, ocaml things its lib should be in one place, when it's actually in a different place.
<gnech>
I have it installed in two places actually
<thelema>
you may be able to get around this with environment variables - is the OCAMLLIB environment variable set?
<gnech>
yeah I have it set
<thelema>
hmm, maybe ocaide is running ocaml within a new environment that doesn't have that variable set... :(
<thelema>
I don't know how to fix that.
_andre_ has joined #ocaml
<thelema>
you can move your library to where ocaml is expecting it... if you have a T drive...
_andre_ has quit [Client Quit]
<thelema>
oh, you do...
andre___ has joined #ocaml
<gnech>
yeah I do have a T drive
<thelema>
oh, what's OCAMLLIB set to?
_andre has quit [Ping timeout: 252 seconds]
ikaros has quit [Quit: Ex-Chat]
<gnech>
T:\Program Files (x86)\ocaml\lib
<thelema>
what ocamlc are you running? (i.e. where is that located)
andre___ has quit [Ping timeout: 245 seconds]
<gnech>
it's in T:\cygwin\bin
<gnech>
one second, I'm going to change OCAMLLIB to T:\cygwin\lib\ocaml (instead of the T:\Program Files...)
<thelema>
sounds like one of your ocaml installations was directing the other to use the wrong library directory
_andre has joined #ocaml
<gnech>
I first installed using the Ocaml installer for windows. Then I installed Camelia and first got these pervasives.cmi errors
<gnech>
then last night I downloaded OcaIDE, and the preferred way is to build Ocaml projects with ocamlbuild (which requires cygwin -- so I downloaded cygwin) and still have the pervasives.cmi problem
<thelema>
somebody will have to fix ocamlbuild to work under windows without cygwin - there's no good reason for the dep...
mnabil has quit [Ping timeout: 252 seconds]
<gnech>
hmm
<gnech>
yeah, it's just frustrating. I can use OcamlWinPlus v1.9RC4 no problems
<thelema>
ocamlbuild is a very good thing, and its use should be encouraged on all platforms
<thelema>
did changing the environment variable fix ocaide?
<thelema>
(you'll probably have to restart ocaide for it to see the new environment)
iago has joined #ocaml
<gnech>
yeah i just restarted and remove all references to ocaml bin/lib that pointed to T:\Program FIles... from PATH and changed them to T:\cygwin\-whatever
sgnb` has quit [Remote host closed the connection]
sgnb`` has joined #ocaml
edwin has quit [Remote host closed the connection]
twittard has quit [Remote host closed the connection]
twittard has joined #ocaml
Submarine has quit [Read error: Operation timed out]
gnech has quit [Ping timeout: 240 seconds]
<Drakken>
My custom toplevel can't open Foo ("Error: Unbound module Foo"), even though "foo.cmo" was passed to ocamlmktop with no error messages.
<mfp>
Drakken: do you have a foo.cmi around?
everyonemines has joined #ocaml
<Drakken>
mfp yes.
<Drakken>
mfp the problem seems to be when I use object files created by ocamlbuild.
antegallya has quit [Quit: Leaving.]
<mfp>
hmm is it maybe because the .cmi is under _build/?
<mfp>
i.e. not in a directory known by the toplevel?
<mfp>
(cf. #directory)
<Drakken>
mfp I don't know. I passed -I _build to ocamlfind ocamlmktop.
<mfp>
what about the toplevel itself? It should also need -I _build
<mfp>
or #directory "_build";;
<Drakken>
mfp that's it :)
Xizor has quit []
<mfp>
my understanding is that the custom toplevel needs to be able to find the .cmi for all the modules you want to refer to directly in the toplevel, but not for those referred to indirectly which were passed to ocamlmktop
<mfp>
e.g. I think that if your Foo module uses some Bar and Baz, it's OK not to have bar.cmi and baz.cmi as long as you don't refer to them directly
<Drakken>
how arbritrary :/
<mfp>
I believe that's because the .cmi is only needed to extract/list the values so that the toplevel can show their types, etc.
<mfp>
OTOH, the Foo module only needs to know the intf digest of bar and baz
<mfp>
which are included in the toplevel in addition to the actual code
<mfp>
so you can in principle include lots of support code in a custom toplevel and a single "entry module" whose .cmi (is the only one) you have to ship
<Drakken>
hmm. I guess the compiler was forced to create interfaces for bar and baz one way or another, but it leaves the interface for foo unspecified.
<Drakken>
(because it can)
<mfp>
AFAIK the only info included in the toplevel about the modules is their code, their interface (digest) and the other interfaces they import
<mfp>
that is, the same info you get with ocamlobjinfo foo.cmo
<mfp>
OTOH the toplevel needs the specifics of the interface (not just the digest), i.e. the .cmi
<Drakken>
Maybe ocaml* should have an option to use the default interface.
<Drakken>
of specified object files.
ikaros has quit [Quit: Ex-Chat]
othiym23 has quit [Read error: Connection reset by peer]