caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re: ocamldep
@ 1996-07-18 21:21 Doug Currie, Flavors Technology, Inc.
  0 siblings, 0 replies; 6+ messages in thread
From: Doug Currie, Flavors Technology, Inc. @ 1996-07-18 21:21 UTC (permalink / raw)
  To: Xavier Leroy, e-posse; +Cc: caml-list


At 3:33 PM 7/18/96, Xavier Leroy wrote:
>> Hello everybody. I have been having a little trouble with the Dependency
>> Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml.
>> The reference manual says that the typical use of ocamldep should be
>> something like this:
>>
>>       ocamldep *.mli *.ml > .depend
>>
>> The problem is that ocamldep doesn't seem to recognize the *.mli and
>> *.ml arguments
>
>Well, the Objective Caml sources come from a Unix background, where
>wildcards (*.ml) are expanded by the command shell and the commands
>receive an already-expanded argument list. One day I may add
>command-line expansion in the Objective Caml start-up code, but don't
>hold your breath.

I did something for the Mac version of Moscow ML to work around the lack of
a UNIX make system. Since the Mac has no UNIX make command, it was
difficult to build the system without it. The code is written in Standard
ML and is available from the Moscow ML site
<http://www.dina.kvl.dk/~sestoft/mosml.html> in the Mac source
distribution, file Smltope.sml. It's about seven pages of code.

Rather than specify the files to compile or link, I did the following
(which works great for mosml, and should also work for O'Caml)...

A new function "make" is given a directory as an argument, along with a
list of other directories to include in the search/include path, and the
library directory. It attempts to compile all the files in the directory
with the right path suffix (.sig and .sml in my case), also checking along
the way that .grm and .lex files have already been processed. It traces out
the dependencies using mosmldep, constructs a dependency matrix, and
computes the transitive closure using Floyd-Warshall. It sorts the files
and compiles those files that need it.

Given a sequence of directories in the right order (e.g., lib, compiler,
linker, toplevel) it gets the whole job done.

A new toplevel function link takes a single object file. It recursively
traces out the file's load dependencies, and then shares code with make to
compute the transitive closure and sort the files into load order, and then
invokes the usual linker on the sorted list.

Below is a clipping from the manual.

e

-=-

make : string -> string -> string list -> string -> unit

Evaluating:

  make <oset> <stdlib> [<dir1>..<dirN>] <path>

is equivalent to running mosmlc as follows:

  mosmlc -P <oset> -stdlib <stdlib> -I <dir1> ..  -I <dirN> <files...>

where <files...> is a subset of the files in directory <path> determined by
tracing out the dependencies among the files and their need for compilation.

-=-

link : string -> bool * bool -> string -> string  \
              -> string list -> string list -> unit

Evaluating:

  link <file> (<g>,<h>) <oset> <stdlib> [<dir1>..<dirN>] [<file1>..<fileN>]

is equivalent to running mosmllnk as follows

  mosmllnk -o <file> {-g} {-noheader} -P <oset> -stdlib <stdlib> \
           -I <dir1> ..  -I <dirN> <file1>..<fileN>

where -g is included if <g> is true, -noheader is included if <h> is true.

If <oset> is "" then it is replaced by "default"
If <oset> is "lorder" then link does the following:
1- trace out all load dependencies of <file1>..<fileN>
2- include in the list of files to be linked all other files depended upon
   if they can be found in any of the specified paths
3- construct a legal link order for the files
4- then link this list as usual

Typically, simply specifying your Main program to be linked will find all
the required .uo files and put them in the right order.

Examples
--------

To create a new mosml project, put all the source files in a new directory,
"project." Don't put any incomplete or irrelevant sources in the same
directory or they will be compiled, too. Assuming your project only depends
on library files, evaluate:

let val base = "pathname of the mosml directory"
in
  make "full" (base ^ "mosmllib") [] (base ^ "project")
end;

to compile all your files. Evaluate this each time you have made changes in
your sources to keep the object files up to date.

Here is a sample make and link script to build mosml.image:

(* ********************************** *)

val home = "pathname of the mosml directory";

moolevel := 2;

(* to compile the toplevel mosml image and the lexer *)

let val base = home ^ ":mosml:src:"
in
  make "none" (base ^ "mosmllib") [] (base ^ "mosmllib");
  make "none" (base ^ "mosmllib") [] (base ^ "compiler");
  make "none" (base ^ "mosmllib") [(base ^ "compiler")] (base ^ "toolssrc");
  make "none" (base ^ "mosmllib") [(base ^ "compiler")] (base ^ "lex")
end;

(* to build the toplevel mosml image into file "testtop.image" *)

let val base = "home" ^ ":mosml:src:"
in
  chDir base; chDir "::";
  link "testtop.image"
       (true,true) (* -g -noheader *)
       "lorder" (base ^ "mosmllib") [(base ^ "compiler"),(base ^ "toolssrc")]
       ["Maine.uo"]
end;

-=-







^ permalink raw reply	[flat|nested] 6+ messages in thread

* ocamldep
  1996-07-19  1:27   ` ocamldep Ian T Zimmerman
@ 1996-07-20 14:48     ` Georg Bauer
  0 siblings, 0 replies; 6+ messages in thread
From: Georg Bauer @ 1996-07-20 14:48 UTC (permalink / raw)
  To: caml-list


Hi!

ITZ>The syntax Xavier suggests for
ITZ>a loop won't work with COMMAND.COM, 

Of course it will work with Command.com. Only problem is, you have to
double the "%" if you put it into a batch file.

ITZ>COMMAND.COM is a shell from hell (rhyme
ITZ>unintentional) or rather from the early 60's...

Ok, _that_ is true. But there are better solutions (for example 4DOS for
DOS-lovers or MKS Toolkit (for those that like more unixlike environments).
There is even a Kornshell plagiat for DOS.

The major problem with DOS isn't O'Caml - you can circumvent all problems
easily, because you have the full source of the runtime library (for
example I made small changes to be able to transparently use "@"-file
redirection to support long command lines) - the major problem with DOS's
commandline is, that _external_ utilities don't support one consistent way
to enable long commandlines. For example the Microsoft Assembler utilities
gave me much headaches to integrate them into O'Caml.

I should hate DOS, because it always gives me much work to do - but
actually I love it. It's just one of the last adventures a man can take ;-)

bye, Georg





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ocamldep
  1996-07-18 13:33 ` ocamldep Xavier Leroy
@ 1996-07-19  1:27   ` Ian T Zimmerman
  1996-07-20 14:48     ` ocamldep Georg Bauer
  0 siblings, 1 reply; 6+ messages in thread
From: Ian T Zimmerman @ 1996-07-19  1:27 UTC (permalink / raw)
  To: Xavier Leroy; +Cc: e-posse, caml-list



In article <199607181333.PAA14029@pauillac.inria.fr> Xavier Leroy
<Xavier.Leroy@inria.fr> writes:

> 
> 
> > Hello everybody. I have been having a little trouble with the Dependency 
> > Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
> > The reference manual says that the typical use of ocamldep should be 
> > something like this:
> > 
> > 	ocamldep *.mli *.ml > .depend
> > 
> > The problem is that ocamldep doesn't seem to recognize the *.mli and 
> > *.ml arguments
> 

> Well, the Objective Caml sources come from a Unix background, where
> wildcards (*.ml) are expanded by the command shell and the commands
> receive an already-expanded argument list. One day I may add
> command-line expansion in the Objective Caml start-up code, but
> don't hold your breath.

> > and I have to list explicitly all of my project files but 
> > I get a "line too long" error from the line command interpreter. (a 
> > MS-DOS window).
> 

> I thought Win32 finally raised the length limit on the command line
> to some reasonable value like 4k. At any rate, you can always split
> the call to ocamldep thus:

>         ocamldep [some files] > .depend
>         ocamldep [more files] >> .depend
>         ...
> 

> Also, a "for" loop may work, for instance
> 
>         for %i in (*.ml) do ocamldep %i >> .depend
> 
> (that's probably the wrong syntax, but you get the idea).

I strongly recommend to the original poster to get djgpp, or at least
the 32 bit perl binary made with djgpp.  The syntax Xavier suggests for
a loop won't work with COMMAND.COM, and you'll have a VERY VERY hard
time finding one that does.  COMMAND.COM is a shell from hell (rhyme
unintentional) or rather from the early 60's...

-- 
                  +-------------------------------------------+
                  I When the dead are left to bury the dead,  I
                  I the living remain alone.  Arthur Koestler I
                  +-------------------------------------------+




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ocamldep
  1996-07-16 23:32 ocamldep Ernesto Posse
  1996-07-17 18:21 ` ocamldep Georg Bauer
@ 1996-07-18 13:33 ` Xavier Leroy
  1996-07-19  1:27   ` ocamldep Ian T Zimmerman
  1 sibling, 1 reply; 6+ messages in thread
From: Xavier Leroy @ 1996-07-18 13:33 UTC (permalink / raw)
  To: e-posse; +Cc: caml-list


> Hello everybody. I have been having a little trouble with the Dependency 
> Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
> The reference manual says that the typical use of ocamldep should be 
> something like this:
> 
> 	ocamldep *.mli *.ml > .depend
> 
> The problem is that ocamldep doesn't seem to recognize the *.mli and 
> *.ml arguments

Well, the Objective Caml sources come from a Unix background, where
wildcards (*.ml) are expanded by the command shell and the commands
receive an already-expanded argument list. One day I may add
command-line expansion in the Objective Caml start-up code, but don't
hold your breath.

> and I have to list explicitly all of my project files but 
> I get a "line too long" error from the line command interpreter. (a 
> MS-DOS window).

I thought Win32 finally raised the length limit on the command line to
some reasonable value like 4k. At any rate, you can always split the
call to ocamldep thus:

        ocamldep [some files] > .depend
        ocamldep [more files] >> .depend
        ...

Also, a "for" loop may work, for instance

        for %i in (*.ml) do ocamldep %i >> .depend

(that's probably the wrong syntax, but you get the idea).

- Xavier Leroy





^ permalink raw reply	[flat|nested] 6+ messages in thread

* ocamldep
  1996-07-16 23:32 ocamldep Ernesto Posse
@ 1996-07-17 18:21 ` Georg Bauer
  1996-07-18 13:33 ` ocamldep Xavier Leroy
  1 sibling, 0 replies; 6+ messages in thread
From: Georg Bauer @ 1996-07-17 18:21 UTC (permalink / raw)
  To: caml-list


Hi!

EP>And by the way, I suppose someone already made the following suggestion 
EP>but it would be very useful to have a "compile" option and a "make" 
EP>option on the menus of ocamlwin.

Actually my DOS-port does have a #compile command for the OCAML interactive
environment. It's easy since you need much of the modules aready to build
OCAML. I didn't include a make facility, because then I would have to
integrate the functionality of ocamldep. Hmm. I should think of that, it
would help much ;-)

bye, Georg





^ permalink raw reply	[flat|nested] 6+ messages in thread

* ocamldep
@ 1996-07-16 23:32 Ernesto Posse
  1996-07-17 18:21 ` ocamldep Georg Bauer
  1996-07-18 13:33 ` ocamldep Xavier Leroy
  0 siblings, 2 replies; 6+ messages in thread
From: Ernesto Posse @ 1996-07-16 23:32 UTC (permalink / raw)
  To: caml-list


Hello everybody. I have been having a little trouble with the Dependency 
Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
The reference manual says that the typical use of ocamldep should be 
something like this:

	ocamldep *.mli *.ml > .depend

The problem is that ocamldep doesn't seem to recognize the *.mli and 
*.ml arguments and I have to list explicitly all of my project files but 
I get a "line too long" error from the line command interpreter. (a 
MS-DOS window).

Does anyone know what the problem is and how could it be solved? Thank 
you. 

And by the way, I suppose someone already made the following suggestion 
but it would be very useful to have a "compile" option and a "make" 
option on the menus of ocamlwin.

I'm sorry if someone already asked this question, I've just joined the 
list and I didn't find anything like this in the FAQ.

I'm also sorry not to include a French abstract of the question but my 
knowledge of the French language is restricted to "Je ne parle pas 
France".

-- 
Ernesto Posse
Estudiante de Ingeniería de Sistemas y Computación
(Systems and Computing Engineering student)
Universidad de los Andes
Santafé de Bogotá
Colombia
e-mail: e-posse@uniandes.edu.co
url: http://wwwest.uniandes.edu.co/~e-posse





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1996-07-22  8:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-07-18 21:21 ocamldep Doug Currie, Flavors Technology, Inc.
  -- strict thread matches above, loose matches on Subject: below --
1996-07-16 23:32 ocamldep Ernesto Posse
1996-07-17 18:21 ` ocamldep Georg Bauer
1996-07-18 13:33 ` ocamldep Xavier Leroy
1996-07-19  1:27   ` ocamldep Ian T Zimmerman
1996-07-20 14:48     ` ocamldep Georg Bauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).