Unix Programming - Re-build rule without changing timestamp

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > September 2004 > Re-build rule without changing timestamp





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Re-build rule without changing timestamp
Roopa

2004-09-09, 7:52 am

Hi,
> I have the following scenario:
> -------------------------------------
> #The contents of the file "foo" are captured in a variable.
> ENV_FILE_CONTENTS := $(shell cat foo)
>
> #pre-requisites for TARGET1 are identified
> $(TARGET1):: $(ENV_FILE_CONTENTS) \
> $(PREQ_REQ2)
>
> #Other stmts...
> ..
> ..
> ---------------------------------
> where "foo" is the file that holds the environment variables that point to
> my project-paths like
> $(ENV1)
> $(ENV2)
> $(ENV3) etc
>
> where in turn $(ENV1),$(ENV2),$(ENV3),etc are set either on command line or
> by using a
> batch file.
>
> By changing the value of 1 or more environment value, can I force gmake to
> re-build the rule without changing the timestamp of the file "foo"?
>
> Help in this regard is highly appreciated,
> Thanks in advance,
> Rgds,
> Roopa

Jens.Toerring@physik.fu-berlin.de

2004-09-09, 5:56 pm

Roopa <roopa.mahishi@philips.com> wrote:[vbcol=seagreen]

If you don't get a reply to a post it normally means either

1) nobody knows how to help you
2) nobody understands your question
3) nobody finds the question interesting enough to answer

In none of these cases it makes any sense to repost exactly the same
question again. In your case I simply have not the slightest idea
what you want to do there. If you would rephrase your question, telling
first what you want to do, and then e.g, what's really in your file foo
(how is a file supposed to "hold" environment variables and in which
form?), what a prerequisite like $(ENV_FILE_CONTENTS) is supposed to
evaluate to and why the above should change the timestamp (which one)
of foo etc. perhaps someone will be able to help you.

If I am not completely mistaken you basically want to get make to
rebuild something if an environment variable has changed since the
last invocation of make. If that is the case how is make supposed
to remember the values the environment variables had on the last
invocation? Make does not store any such information, so you will
have to write out the values of the variables to some file yourself
and in the new invocation compare these values to the ones the
variables have now. If they differ you could e.g. delete every
target and then make everything anew plus write out the file with
the new values of the environment variables that got used in the
rebuild.

Perhaps something like this (please note: untested) gives you some
idea how to get it working:

all:
if [ -e foo ]; then \
$(MAKE) check_foo; \
else \
$(MAKE) clean; \
$(MAKE) foo.new; \
mv foo.new foo; \
fi
$(MAKE) real_target;


check_foo: foo.new
diff foo foo.new >/dev/null 2>&1
if [ $? ]; then \
mv foo.new foo; \
$(MAKE) clean; \
else \
rm foo.new; \
fi


foo.new:
echo $(ENV1) > foo.new
echo $(ENV2) >> foo.new
echo $(ENV3) >> foo.new


real_target: foo
do_whatever_is_needed_to_build_the_real_
target


clean:
delete_everything_that_gets_made_by_real
_target

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nick Landsberg

2004-09-09, 5:56 pm

Jens.Toerring@physik.fu-berlin.de wrote:

> Roopa <roopa.mahishi@philips.com> wrote:
>
>
>
> If you don't get a reply to a post it normally means either
>
> 1) nobody knows how to help you
> 2) nobody understands your question
> 3) nobody finds the question interesting enough to answer
>
> In none of these cases it makes any sense to repost exactly the same
> question again. In your case I simply have not the slightest idea
> what you want to do there. If you would rephrase your question, telling
> first what you want to do, and then e.g, what's really in your file foo
> (how is a file supposed to "hold" environment variables and in which
> form?), what a prerequisite like $(ENV_FILE_CONTENTS) is supposed to
> evaluate to and why the above should change the timestamp (which one)
> of foo etc. perhaps someone will be able to help you.
>
> If I am not completely mistaken you basically want to get make to
> rebuild something if an environment variable has changed since the
> last invocation of make. If that is the case how is make supposed
> to remember the values the environment variables had on the last
> invocation? Make does not store any such information, so you will
> have to write out the values of the variables to some file yourself
> and in the new invocation compare these values to the ones the
> variables have now. If they differ you could e.g. delete every
> target and then make everything anew plus write out the file with
> the new values of the environment variables that got used in the
> rebuild.
>
> Perhaps something like this (please note: untested) gives you some
> idea how to get it working:
>
> all:
> if [ -e foo ]; then \
> $(MAKE) check_foo; \
> else \
> $(MAKE) clean; \
> $(MAKE) foo.new; \
> mv foo.new foo; \
> fi
> $(MAKE) real_target;
>
>
> check_foo: foo.new
> diff foo foo.new >/dev/null 2>&1
> if [ $? ]; then \
> mv foo.new foo; \
> $(MAKE) clean; \
> else \
> rm foo.new; \
> fi
>
>
> foo.new:
> echo $(ENV1) > foo.new
> echo $(ENV2) >> foo.new
> echo $(ENV3) >> foo.new
>
>
> real_target: foo
> do_whatever_is_needed_to_build_the_real_
target
>
>
> clean:
> delete_everything_that_gets_made_by_real
_target
>
> Regards, Jens


There is at least one (not-free) variant of "make"
which actually does keep track of the environment
variable settings when the last build was done.

Google for "nmake" (but ignore the pointers to
Microsoft Sites).

To quote from one of the links there:

[ begin quote ]

nmake(1) is the standard software construction tool at AT&T and Lucent
Technologies. It is a descendent of the UNIX make(1) and is not related
to the Microsoft program of the same name.

[ end quote ]

I did some beta testing for it back about 15 years ago
and, back then, it was a nice package. It might still
be, I just don't know anymore.

e.g. if you changed $CCFLAGS, (not just CFLAGS), you
would probably trigger a complete build. If you
changed $MY_INCLUDE_DIR, everything which had a
depedency on it would be rebuilt. You also did not
have to specify any include file dependencies, since
it believed you were a liar, and run a version of
the C-preprocessor to find out all the include file
dependencies. Lest this turn out sounding like
a salespitch ... I no longer have any association
with the product. I just think it's neat.

alternatively, get a source version of "makedepend(1)"
and munge it to include the set of environment
variables you are interested in and drop them
into the generated makefile as "make" variables
and dependencies. This may be tricky

NPL




NPL

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Ian Zimmerman

2004-09-22, 9:21 pm


Jens> you basically want to get make to rebuild something if an
Jens> environment variable has changed since the last invocation of
Jens> make. If that is the case how is make supposed to remember the
Jens> values the environment variables had on the last invocation? Make
Jens> does not store any such information, so you will have to write out
Jens> the values of the variables to some file yourself and in the new
Jens> invocation compare these values to the ones the variables have
Jens> now.

Nick> There is at least one (not-free) variant of "make" which actually
Nick> does keep track of the environment variable settings when the last
Nick> build was done.

There is also makepp (http://makepp.sf.net) which forces a rebuild
whenever the expanded command that creates a target changes; that would
account for most uses of the environment, I'd think.

--
"It's not true or not." A reality show producer (real quote)
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com