l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
September 2: Social gathering
Next Installfest:
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2007 May 04 19:37

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Make with _possibly_ cascading dependencies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Make with _possibly_ cascading dependencies

On Thursday 03 May 2007 05:42:37 pm Bill Kendrick wrote:
> This isn't Linux-related, but is make-related ("nmake",
> specificlaly), so I thought I'd ask here. :^)
> In the mobile phone software world, you often end up building
> numerous versions of the same app, to address differences between
> handsets (e.g., use different art assets, depending on the screen
> sizes; handset screens differ wildly in size and aspect ratio).
> An application I'm working on has had the same data shared across all
> builds (let's name a few of the builds "M", "L" and "XL", for
> example). In my project, I have a data file that gets used during the
> build process.  We now need to be able to use _build-specific_
> versions of this file, for some builds.  (Honestly, it's insanely
> more complicated than all this, but I'm trying to boil it down, for
> consumption :^) )
> Example:
>   foo.xyz : DATA\foo.in
>   	process DATA\foo.in > foo.xyz
> Now, I want to be able to check whether there's a build-specific
> dependency. If so, I want to use it, rather than the 'default' one.
> e.g.:
>   foo.xyz : DATA\$(SIZE)\foo.in    # Where SIZE is "M", "L" or "XL"
>   	process DATA\$(SIZE)\foo.in > foo.xyz
> If and only if it exists... otherwise, use the default one, as shown
> above.
> My first idea is to just junk the dependency part of the target...
> when I make my builds, I'm always cleaning everything first, anyway. 
> *sigh*
> e.g.:
>   foo.xyz :
>   	# Do the default first:
>   	process DATA\foo.in > foo.xyz
>   	# Then try to override it with a build-specific one, if it exists:
>   	if EXISTS DATA\$(SIZE)\foo.in   process DATA\$(SIZE)\foo.in >
> foo.xyz
> An even worse variation on the above is to generate a temp file
> first:
>   foo.xyz : DATA\foo.in.temp
>   	process DATA\foo.in.temp > foo.xyz
>   foo.in.temp :
>   	# Copy the default file into a temp file, first
>   	copy DATA\foo.in DATA\foo.in.temp
>   	# Overwrite the temp file with a build-specific one, if it exists:
>   	copy DATA\$(SIZE)\foo.in DATA\foo.in.temp
> Ideas?

Does nmake support pattern rules like GNU make? If so, and your data is 
suitably organized for a pattern rule, then you can just use those.

[bloom@cat-in-the-hat test]$ cat Makefile
all: test.a
%.a: %.b
	cp $< $@
%.a: %.c
	cp $< $@
[bloom@cat-in-the-hat test]$ echo c > test.c
[bloom@cat-in-the-hat test]$ make
cp test.c test.a
[bloom@cat-in-the-hat test]$ rm test.*
[bloom@cat-in-the-hat test]$ echo b > test.b
[bloom@cat-in-the-hat test]$ make
cp test.b test.a
[bloom@cat-in-the-hat test]$ rm test.*
[bloom@cat-in-the-hat test]$ echo c > test.c
[bloom@cat-in-the-hat test]$ echo b > test.b
[bloom@cat-in-the-hat test]$ make
cp test.b test.a

Just make sure the most general rule is last.

Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.

Attachment: pgp00000.pgp
Description: PGP signature

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!