axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] build issue?


From: Page, Bill
Subject: RE: [Axiom-developer] build issue?
Date: Fri, 18 Feb 2005 05:52:48 -0500

Tim,

On Thursday, February 17, 2005 10:32 AM you wrote:
> 
> in src/etc/Makefile, in the <<dbcomplete>> chunk there is a
> prerequisite of:
> 
> ${INT}/algebra/*.NRLIB/code.o
> 
> but there is no stanza to address this rule.

That is normal.

The *.NRLIB/code.o files are intermediate files that are
actually created by the src/algebra/Makefile. Since they
are intermediate, as far as src/algebra/Makefile is
concerned, they are not needed unless some target that
explicitly depends on them, e.g. the ${OUT}/%.o files,
needs to be rebuilt.

The rule in src/etc/Makefile

  ${MNT}/${SYS}/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o

is a "wildcard" rule which says that the *.daase files
depend on all of the *.NRLIB/code.o files that exist at
the time the sub-make is run (i.e. those that were previously
created by the src/algebra/Makefile). The databases will
be re-built if any of these files have dates later than
the database files.

> This only shows up if you remove the code.o files. 
>

It does not really make sense to delete only the code.o
files. That is like saying that these are no longer needed
to build the daase files.

You could delete *both* the ${OUT}/%.o files as well as
the code.o files. That will trigger all of them to be
re-build in src/algebra/Makefile. Or alternatively if your
goal is just to re-build the code.o files then

  touch int/algebra/*.spad

should work even better.
 
> This is somehow related to the generic rule effort but
> I don't see how to resolve it.

Yes. More specifically it is related to the use of implicit
rules which are treated in a subtly different way than explicit
rules when it comes to intermediate files. The code.o files
are not re-created unless some explicit rule calls for them.
Deleting the ${OUT}/%.o files before running make will cause
the code.o files to be created.

If deleting both the ${OUT}/%.o files and the code.o files or
using 'touch int/algebra/*.spad' does not seem satisfactory
to you, then we should move <<dbcomplete>> back to the
src/algebra/Makefile and replace the simple wildcard rule
with an explicit list of code.o files built from the
${SPADFILES} list by patterns substitutions - the way you
do it in the src/interp/Makefile. It would be something like
this:

${OUT}/*.daase: \
    ${SPADFILES:${OUTSRC}/%.spad=${MID}/%.NRLIB/code.o}

Probably the internal $ in the patterns have to be escaped
with \$ . I know you never liked the idea of moving
<<dbcomplete>> from algebra to etc anyway. :)

If you want, I can experiment with this change in my next
patch to axiom--windows--1.

> 
> To trigger the problem remove the code.o files and
> type make.
> 

Can you try deleting the ${OUT}/%.o files and the code.o
files and see if that does what you want?

In my fixedPoint script this problem does not happen
because I use

  touch int/algebra/*.spad

If your goal is to cause the code.o files to be re-built
using the optimization information in the NRLIBS from a
previous build, then I think this should also work for
you.

Regards,
Bill Page.




reply via email to

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