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
next prev 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