Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Daniel Bünzli" <daniel.buenzli@epfl.ch>
To: OCaml List <caml-list@inria.fr>
Subject: Re: [Caml-list] ocamlbuild and subdirectories
Date: Fri, 25 May 2007 16:34:58 +0200	[thread overview]
Message-ID: <A7CF24A7-09F8-4129-BEA0-5FB4299E9E70@epfl.ch> (raw)
In-Reply-To: <cd67f63a0705250531n1b24aa4cqaf1d77cd795f5d26@mail.gmail.com>


Le 25 mai 07 à 14:31, Nicolas Pouillard a écrit :

> Yes our system to move things out of the build is really partial
> (since we still don't what a good way will be). I often use a shell
> script to install things, or start it directly from the build.

Regarding executables I think the symbolic link should not be put in  
the directory in which ocamlbuild is invoked. Either put it in the  
directory in which the target ml file is or do not create links at  
all. In a case I have a directory layout conceptually similar to this :

> > ls */*
> src/a.ml                test/test.ml
> src/a.mli               testalt/test.ml

So each time I build one of the test executable with

> > ocamlbuild -I src test/test.native

or

> > ocamlbuild -I src testalt/test.native

it changes the symbolic link test.native in the root directory.  
However I would like to have both executables at hand hence I'd  
prefer the symbolic links to be respectively created in test and  
testalt. It is annoying because I never remember which test I last  
built when I invoke test.native and often end up with the wrong one.

But putting links in subdirectories means more work for ocamlbuild - 
clean. Maybe the best alternative is to not create symbolic links at  
all and force the user to hunt in _build or to use

> > ocamlbuild -quiet -I src test/test.native --
> > ocamlbuild -quiet -I src testalt/test.native --

to launch its executables. This avoids any symbolic link confusion.


Le 25 mai 07 à 14:49, Joel Reymont a écrit :

> I totally love ocamlbuild, btw, I think it's awesome!

I concur, there is something magic about it. But there are minor  
points that annoy me at the moment  (e.g. by default the _log file  
should be written in the _build/ directory, and apparently the emacs  
mode was not updated to look for .annot files in the _build directory).

Best,

Daniel


  parent reply	other threads:[~2007-05-25 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-25 11:20 Joel Reymont
2007-05-25 11:34 ` [Caml-list] " Nicolas Pouillard
2007-05-25 11:43   ` Joel Reymont
2007-05-25 12:27     ` Nicolas Pouillard
2007-05-25 11:46   ` Joel Reymont
2007-05-25 12:31     ` Nicolas Pouillard
2007-05-25 12:35       ` Joel Reymont
2007-05-25 12:47         ` Nicolas Pouillard
2007-05-25 12:49           ` Joel Reymont
2007-05-25 14:34       ` Daniel Bünzli [this message]
2007-05-25 16:59         ` Nicolas Pouillard
2007-05-26 12:36           ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A7CF24A7-09F8-4129-BEA0-5FB4299E9E70@epfl.ch \
    --to=daniel.buenzli@epfl.ch \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox