[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3DLDF (fwd)

From: Laurence Finston
Subject: Re: 3DLDF (fwd)
Date: Fri, 14 Nov 2003 19:32:49 +0100 (MET)

---------- Forwarded message ----------
Date: Fri, 14 Nov 2003 11:38:41 +0100 (MET)
From: Laurence Finston <address@hidden>
To: Tom Tromey <address@hidden>
Cc: Alexandre Oliva <address@hidden>,
     Alexandre Duret-Lutz <address@hidden>, address@hidden, address@hidden
Subject: Re: 3DLDF

Dear Automake maintainers,

I received the following message from Richard Stallman, who also sent it
to you. My problem is that the default behavior of Autoconf and Automake
doesn't account for the consequences of using CWEB.

Are there other GNU maintainers using CWEB? If there are, maybe
someone's already solved the problems described below.

I've written 3DLDF in C++ using CWEB, so my source files are
points.web, etc. When they are ctangled, they produce transfor.c,
etc. In addition, ctangle generates header files transfor.h, points.h,
etc., from the CWEB files. CWEB files that are
processed later  can
depend on header files generated from CWEB files that were
processed before.

Each time ctangle is run on a CWEB file `a.web', the header file `a.h' is
generated, so it will be newer than `b.web', which depends on it. make
would therefore recompile `b.c'. However, `a.h' might not have
changed since the last time `ctangle a.web' was run, so recompiling
`b.c' and other .c files that depend on `a.h' would be a waste of time
(unless they need to be recompiled for another reason).

To solve this problem, I've written a second program, LDF3DCPL, which
manages retangling, recompilation, and relinking of LDF3D (I couldn't
call the executables 3DLDFCPL and 3DLDF, as explained below).
It uses diff to determine whether a header file has changed since its
last version, and procedes accordingly.
this causes the `dist' target generated by Automake to fail, because
it can't find a rule for generating the .cxx files. Even if it could,
the .c or .cxx files shouldn't be included in a distribution when CWEB
is used. I tried defining
an explicit `dist' target, but it failed to override the automatically
generated one. I also tried using `nodist_LDF3D_SOURCES' (I think
that's what it's called, I don't have my Automake manual handy). I've
written a `distrib' target, which should be used
instead, but clearly my should be conformant to the GNU

I've had an idea for getting retangling, recompilation, and relinking
to work using make alone, by putting the diff command in a rule, and
touching or not touching a dummy file for each header file, but I
haven't tried it yet. I'm not sure it would be a good idea to use it,
because make would then always be needed to run LDF3D.

I think there may be other problems with the automatically-generated
make targets, but since I don't understand how they're coded yet, I
don't want to mess about with them.  In particular, I don't think
clean does what I'd like.

I was unable to call the executables "3DLDF" and "3DLDFcpl", because
the variables (or are they macros?) "3DLDF_SOURCES" and
"3DLDFcpl_SOURCES" caused errors in Automake.

LDF3DCPL is regenerated using the basic facilities of make, because
its source files, 3DLDFcpl.web and 3DLDFprc.web, don't generate
header files.  However, it's necessary to change the extension of the
generated C++ files from .c to .cxx in the rule, because make
otherwise uses gcc instead of g++.

I'd really appreciate it if you could help me with these problems, or
point me in the right direction to find the answers.


Laurence Finston

On Wed, 12 Nov 2003, Richard Stallman wrote:

>     I had some trouble because the default behavior of Autoconf and Automake
>     doesn't account for the consequences of using CWEB, and I don't yet
>     understand Autoconf and Automake well.
>     I was able to work around most
>     problems, but `make dist' fails, and I wasn't able
>     to override it by defining an explicit `dist' target. Instead, I've
>     defined a `distrib' target that should be used instead. Some of the other
>     default targets may not work, either, but I've defined others
>     that should be used instead. I document this in README and in the _User
>     and Reference Manual_.
> 3DLDF is about to become a GNU package, and needs to have a proper
> standards-conforming makefile.  Automake maintainers, would you please
> help Laurence Finston figure out how to use Automake for this
> particular unusual situation?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]