From: Judicael Courant <Judicael.Courant@lri.fr>
To: stephanh@win.tue.nl
Cc: caml-list@inria.fr
Subject: Re: Why does the order in the Makefile matter?
Date: Fri, 03 Nov 2000 08:24:29 +0100 [thread overview]
Message-ID: <3A02682D.7BC56F72@lri.fr> (raw)
In-Reply-To: <200011021822.TAA11126@pauillac.inria.fr>
Pierre Weis a écrit :
> > So it would be nice if the compiler itself could put the .cmo files
> > in an order compatible with the static binding rule. This would
> > remove the tedium of putting the .cmo files in an appropriate order
> > from the programmer.
>
> We can propose an external tool that will try to find for you some
> order compatible with static binding if any, something similar to
> ocamldep for module compilation dependancy. This existed in Caml Light
> and was named ``lorder'':
>
> lorder
> ------
> A tool to compute the dependencies between a set of .zo files
> and suggest a correct linking order.
>
> > Would this be difficult to implement?
>
It is quite easy to implement in bash, using sed and the tsort Unix
utility (in the code of xxargs, you may notice that bash supports
higher-order functions!). I have already done it (*).
Here are the functions you need:
-------------------------------------------------------------
# general-purpose function
# xxargs f reads lines on its standard input an applies f to each
# of them, in order
# ignores the last line if it does not end with a newline
xxargs ()
{
local F
local ARGS
F=$1
while read ARGS
do
$F $ARGS
done
}
# takes a list of dependency with form
# f f1 ... fn
# meaning f depends on f1 and ... and fn
# and outputs a list within tsort format
format ()
{
read f l
while [ "$f" != "" ]
do
set -- $l
while [ "$1" != "" ]
do
echo $1 $f
shift
done
read f l
done
}
# tidy the input: if a line begins
# with a .cmi or .cmx, we ignore it, since we want to know the
# relations between .cmo files (in order to link).
# otherwise, delete the ":", and change .cmi into .cmo in order to
# have the "must be linked before" relation (if the corresponding .mli
file
# has no associated .ml file, this can introduce fake .cmo files)
# files, that is, files t)
# Moreover, we delete the prefix "./" in filenames
tidy ()
{
case "$1" in
*.cmo:) echo "$@" | sed -e "s/://g" -e "s/.cmi/.cmo/g" -e "s|\./||g";;
*) ;;
esac
}
# removes .cmo that would not have a corresponding .ml
tidyout ()
{
local BASE
local DIR
BASE=`basename $1 .cmo`
DIR=`dirname $1`
if [ -f "$DIR/$BASE.ml" ]
then
echo "$1"
fi
}
# takes a list of dependencies in ocamldep format and outputs
# the topologically sorted list of .cmo
# typical usage:
# ocamldep -I foo foo/*.ml foo/*.mli *.ml .mli | order
# or: cat .depend
order ()
{
xxargs tidy | format | tsort | xxargs tidyout
}
-------------------------------------------------------------
Enjoy!
Judicaël Courant.
(*) When I wrote this, my aim was to have a script to automagically
check that the code of my students' would compile and do some automated
tests over it. For security reasons (the students would submit through
an anonymous web form), I did not want to do just a "make all". So I
wrote a script that just did the necessary job. The above functions are
part of the script. More about this if anybody is interested.
--
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Montre moi des morceaux de ton monde, et je te montrerai le mien"
Tim, matricule #929, condamné à mort.
http://rozenn.picard.free.fr/tim.html
prev parent reply other threads:[~2000-11-03 9:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-28 8:01 Mattias Waldau
2000-10-28 16:55 ` Pierre Weis
2000-10-30 8:30 ` Why does the order in the Makefile matter? --- Linking with C kahl
2000-10-31 7:39 ` Why does the order in the Makefile matter? Mattias Waldau
2000-11-01 7:38 ` Stephan Houben
2000-11-02 18:22 ` Pierre Weis
2000-11-03 7:24 ` Judicael Courant [this message]
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=3A02682D.7BC56F72@lri.fr \
--to=judicael.courant@lri.fr \
--cc=caml-list@inria.fr \
--cc=stephanh@win.tue.nl \
/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