ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Touset <step...@touset.org>
Subject New to ant, having some problems
Date Wed, 15 Oct 2003 07:17:01 GMT
I'm trying to set up a build file for ant to set up two callable
targets: release and debug. Release will enable some compiler
optimizations, and debug will enable gdb debugging symbols. However,
I've run into some problems.

First off, I'm sure there's a way to easily debug a build.xml file, but
I've been unable to find one as of yet. I know there are problems in my
build file, but I could probably work out the kinks easier if I knew a
way to debug it and/or step through.

Next is that my approach seems rather "hackish". There doesn't seem to
be an easy way to set compiler options based upon the target called.
This would be extremely easy if there were a built-in property in ant
that represented the originally called target, but alas, I can find no
such option. I'm sure, however, that there must be a way to do this
reasonably. My current solution is to have the release and debug targets
call a setrelease and setdebug target, respectively, before going into
the build. These set a "release" or "debug" property, and antcall my
build target, inheriting properties.

I think that should work, but I'm still running into problems. I've got
ccflags, ccreleaseflags, and ccdebugflags properties set at the base of
the build.xml file. In my build target, I specify three compilerargs:
${ccflags}, ${ccdebugflags} if ${debug} is set, and ${ccreleaseflags} if
${release} is set. However, there seems to be something wrong with this
approach, as my resulting executable does not have debugging symbols
when I call the debug target. I've tried different ways of consolidating
these, but to no avail.

Lastly, I think my method of solving the problem of creating two
different builds causes a problem in the dependency tree. Since I really
only have two separate builds to change flags in one section, I can have
the two branches of the tree (release and debug targets) converge onto
one target (build). However, this mucks with the dependencies, and I
would assume just isn't a generally palatable solution.

So what's my best option? Am I going down the right path, with a few
errors, or should I completely redo my concept of the build.xml file,
using two completely divergent trees?

I've included my build.xml file for reference, and hopefully for
pointers/solutions.

-- 
Stephen Touset <stephen@touset.org>

Mime
View raw message