[vox-tech] Make with _possibly_ cascading dependencies
Bill Kendrick
nbs at sonic.net
Thu May 3 15:42:37 PDT 2007
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?
--
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
More information about the vox-tech
mailing list