l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2007 May 03 17:56

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)
[vox-tech] Make with _possibly_ cascading dependencies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] Make with _possibly_ cascading dependencies



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@newbreedsoftware.com
http://www.newbreedsoftware.com/
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.