I believe and <include> directive made it into the requirements for ANT2.
Notice that you can use XML external entities to do includes today, the only
problem is that you cannot use ${param} substitutions on them. Which is why
some sort of include directive is being considered.
Jose Alberto
> -----Original Message-----
> From: Peter Vogel [mailto:pvogel@arsin.com]
> Sent: Wednesday, May 16, 2001 11:57 PM
> To: 'ant-user@jakarta.apache.org'
> Cc: 'ant-dev@jakarta.apache.org'
> Subject: Abstracting builds (Was RE: Automatically generating build
> files)
>
>
> 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.
> >
>