Unix Programming - makefile delimma

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > November 2004 > makefile delimma





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 makefile delimma
Billy Patton

2004-11-18, 7:47 am

I have been working for the last week on a prototype flow controller using a
set of makefiles. Trent has been VERY helpful.

Here's my delimma.
I have, currently, 4 tasks which must be done.
all: task1 task2 task3 task4

Each of the tasks call a seperate makefile. (the top sets environment
variables)

Each of these individual tasks are dependant of several files within a
clearcase vob. THese files MUST exist for that task to run. BUT, here's the
problem. I still need to know when the data did not exist. I don't want
to write seperate scripts, one to run and one to report missing data. It
seems my only choice is to have a wrapper that will check for the existance
of the required data and report in the .lis it is missing. BTW all stdio is
captured in task.lis

So if make is going to bomb when one or more of the dependancies are missing
this will not get the .lis file and it is part of what I use to create a .proof
file.


So if I use the -k switch and the dependancy is not there will the make
continue to run?
If it does continue. then the script may die because of no data. If the script
dies, dependant on the original author, I may get no feedback other than a
segmentation violation.

So I need to have wrappers that will take unvalidated input.
check for it's existance.
run the task if all data exists |tee to .list and stdout

I believe I'm seeing what is the problem.
I need to use make file for just determining success or failure and let
wrappers determine about the data.
I'll have to duplicate the dependancy functionality in PERL or bash

If you don't follow what I'm writing don't worry. Typing this has clarified a
lot for me. I was trying to do TOO much in a makefile.

I need to drop back and rethink if make can actually do anything to benefit or
would it be just one more way to skin a cat

___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-patton@ti.com
Trent Buck

2004-11-18, 7:47 am

Quoth Billy Patton on or about 2004-11-18:
> So if I use the -k switch and the dependancy is not there will the make
> continue to run?


If I understand the question correctly, then yes. Consider

a b c x z:
@echo '$+ -> $@'
y:
false
a: b c
x: y z

If you try to make a and x (i.e. `gmake x a'), when y fails (because
false returns false) if the a-b-c chain is not finished, it will
continue. Or so I believe.

> If it does continue. then the script may die because of no data. If the script
> dies, dependant on the original author, I may get no feedback other than a
> segmentation violation.


Although the a-b-c chain continues to build, the x-y-z chain has stopped
at y; that is, make will not attempt to build x. Or so I believe.

> So I need to have wrappers that will take unvalidated input.
> check for it's existance.
> run the task if all data exists |tee to .list and stdout


I can't say, from what you've told me. Hopefully remarks above will
make this clear.

> I need to use make file for just determining success or failure and let
> wrappers determine about the data.


That sounds like a very good idea. Make is good at determining the
build order given a set of dependencies, and good at stopping when
something fails to work. It isn't good at passing data between
targets (other than success / failure).

-trent
PS: A trivial trick that impresses PHBs is to turn the make dependencies
into a graphviz diagram. It might help you visualize the, er, flow too.
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com