On Tue, Sep 29, 2009 at 12:50, Dalton, Tom <tom.dal...@eds.com> wrote:
> Hi,
>
> 1.
> I am using Ant to manage the build and deployment of a collection of
> third party software that's used within my main product. For example, my
> third_party component contains versions of java, gcc, libpng, graphviz,
> valgrind etc etc etc. These packages have dependencies on other packages
> in the component and some on the underlying OS (which I'm not interested
> in). Because all these third_party components use their own build system
> (most use autoconf/automake, some use boost jam, some use cmake, some
> are compressed binary distributions), my projects use the <exec> task
> extensively to run the packages own build systems, with nested <env>
> elements to ensure that the PATH, LD_LIBRARY_PATH and other similar
> things are all set consistently.
>
> Is it possible to wrap the nested <env> elements up into a single
> element?
>
> At the moment I have an init-like rule that sets up properties of the
> form
>
> <property name="buildEnv.PATH" value="blah:blah:blah"/>
> <property name="buildEnv.LD_LIBRARY_PATH" value="blah:blah:blah"/>
> <property name="buildEnv.CC" value="ccache gcc"/>
> <property environment="buildEnv"/>
>
> Later on, in each stage of the build (e.g. configure, build, install) I
> have to do something like
>
> <exec dir="blah" executable="./configure">
> <env name="PATH" value="${buildEnv.PATH}"/>
> <env name="LD_LIBRARY_PATH" value="${buildEnv.LD_LIBRARY_PATH}"/>
> <env name="CC" value="${buildEnv.CC}"/>
> </exec>
>
> Now, I am getting quite a lot of env vars set up (some of the sub-builds
> have 10 or so), and it's getting *horribly* repetitive in all the sub
> build files. Is there a nice way to avoid this? I recently discovered
> the joy of <macrodef>, but I think that can only define a sequence of
> sequential tasks, but not nested elements within tasks...
>
> Any help gratefully received!
>
Depending on which distribution you use, you'd better make packages
for your components, AND first check whether binary packages already
exist for your distribution.
I do this all the time with RPM: I build my packages only if necessary
(otherwise, that's dag.wieers.com - if you do use RPM, you should
throw an eye there), make a virtual package and all I have to do
afterwards is "yum -y install thevirtualrpmname". One command,
everything installed.
Consider this before attempting to replace perfectly sensible, and
working, packaging solutions.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
