ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject Abstracting builds (Was RE: Automatically generating build files)
Date Wed, 16 May 2001 22:57:15 GMT
Congratulations! You've just discovered one of the "truths" about
large system builds.  Lots of stuff to build almost all of it builds
in exactly the same way.

In the world of GNUMake, I routinely move all the common build stuff
up into a pair of files: make.config and make.targs and then I 
do this in each individual makefile:

TOPDIR=<top of tree>
include ${TOPDIR}/make.config

UNIX_LIBRARIES=foo.a bar.a
WIN32_LIBRARIES=foo.lib bar.lib
SRCS_foo =foo.c zoo.c 
SRCS_bar =bar.c zar.c

include ${TOPDIR}/make.targs

And everything happens correctly depending on whether the make is
taking place on a win platform or a unix platform.  All the complex
"guts" of the build system are in the make.targs and make.config dir,
but I KNOW that everything builds under an absolutely controlled 
environment, and I can stake my job on the fact that a build I do today
will be identical to the build I do three months from now using the same
source contour.

In the world of ant, we can do some of the same things, and in many ways
the description is more elegant, unfortunately, the lack of some features
in ant (i.e. true conditional expressions, ability to specify an environment
to take effect for ALL subprocesses invoked by ant, and ability to include 
one file from another (other than properties) make it truly hard to reach
this level of abstraction.  The closest I can come up with is something
like this:

<project name="myproj" basedir="." default="build">
     <target name="init">
         <property file="${basedir}/build/ant.config"/>
         <property name="srcs" value="src"/>
     </target>
     
     <target name="build" depends="init,${prebuild}">
         <javac srcdir="${srcs}" destdir="${classes}">
	       <classpath refid="global.classpath"/>
	   </javac>
         <jar jarfile="${lib}/${ant.project.name}.jar"
basedir="${classes}"/>
	</target>
</project>

But ideally I'd be able to include a standard set of targets which are
properly
abstracted (like the stuff above) to allow a great deal of flexibility in
the 
individual build.xml files while allowing the "typical" build.xml to be just
a few lines:

<project name="myproj" basedir="." configdir=".." default="build">
    <include file="${configdir}/build/ant.config"/>
    <target name="local_init">
        <property name="srcs" value="src"/>
    </target>

    <include file="${configdir}/build/ant.targs/>
</project>

Something for the ant-dev community to mull over...

>
> -----Original Message-----
> From: Shaikh, Mehmood [mailto:Mehmood.Shaikh@ccra-adrc.gc.ca]
> Sent: Wednesday, May 16, 2001 1:04 PM
> To: 'ant-user@jakarta.apache.org'
> Subject: RE: Automatically generating build files
> 
> 
> Most of the software we develop here is very simple. It 
> consists of some
> framework components, common components, and business 
> specific components,
> some of which use 3rd party libraries.
> 
> I organize my build files as one build file per package. I've 
> come up with
> pattern in build files, i.e. every build file i have falls 
> under one of
> several templates. Now i should be able to generate a build file for a
> package by recognizing pattern for that package.
> 
> Any ideas?
> 
> Thanks
> 
> MS.
> 
> 
> -----Original Message-----
> From: Shaikh, Mehmood [mailto:Mehmood.Shaikh@ccra-adrc.gc.ca]
> Sent: May 16, 2001 12:29 PM
> To: 'ant-user@jakarta.apache.org'
> Subject: Automatically generating build files
> 
> 
> Hi,
> 
> I intend to automatically generate build files for my 
> packages by looking at
> my java programs, one thing this requires is the ability to resolve
> dependencies. e.g. if class A imports a class B which is not 
> in my package,
> i want to know that and make a list, then go after that class 
> etc. etc.
> etc...
> 
> For this purpose i need to parse my java program, to be able 
> to get all the
> import statements and go on from there.
> 
> Does this make sense? Any ideas? 
> 
> Thanks
> 
> MS.
> 

Mime
View raw message