gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] <property/> considered messy
Date Tue, 29 Mar 2005 16:29:28 GMT
Leo Simons wrote:
> Hi troopers!
> 
> Right now it is possible to customize build behaviour based on <property/>,
> <arg/> and <jvmarg/> (the latter only for java projects only, of course).
It
> is possible to refer to four types of information:
> 
>  * home directory of another project
>  * jar filename produced by another project
>  * jarpath to jar producted by another project
>  * scrdir directory of the srcdir of another project
> 
> And it is possible to do so independently of actually depending on a
> particular project.
> 
> I think it doesn't make sense that you can refer to something about some
> project without depending on it. If you need to be aware of the project to
> do your build, isn't that some form of dependency? If that is the case,
> <property/> inside <ant/> right now should automatically mean a <depend/>
> (right now a <depend/> inside <ant/> also means a <property/>).
> 
> I believe it is desireable and possible to generalize these references to be
> able to customize a whole lot of other things about the environment that is
> available when gump runs a command to build a particular project. Imagine
> being able to:
> 
>  * export environment variables
>  * depend on environment variables
>  * export new build tools
>  * depend on new build tools
> 
> For example, we might compile kaffe, and then we might want to use kaffe to
> build other projects. Right now, that's simply not cleanly possible (so we
> have a separate kaffe gump run), since that dependency is on an environment
> variable (JAVA_HOME) that ant depends on. Imagine:
> 
> <project name="gcc">
>   <command id="cc"/><!-- path automaticallly determined from $PATH -->
>   ...
> </project>
> 
> <project name="kaffe">
>   <!-- requires -->
>   <depend project="gcc" type="command" id="cc"/>
> 
>   <!-- provides -->
>   <env id="JAVA_HOME" value="[self.home]/build"/>
>   <command id="java" path="[env.JAVA_HOME]/bin/java"/>
>   <command id="javac" path="[env.JAVA_HOME]/bin/javac"/>
>   ...
> </project>
> 
> <project name="sunjdk-1.4">
>   <!-- provides -->
>   <env id="JAVA_HOME"/><!-- value assumed to be set by gump -->
>   <command id="java" path="[env.JAVA_HOME]/bin/java"/>
>   <command id="javac" path="[env.JAVA_HOME]/bin/javac"/>
>   ...
> </project>
> 
> <alias name="jdk" project="kaffe" if="[projects.kaffe.success]"/>
> <alias name="jdk" project="sunjdk-1.4" if="[not projects.kaffe.success]"/>
> 
> <project name="ant">
>   <!-- requires -->
>   <depend project="jdk" type="env" id="JAVA_HOME" runtime="true" />
>   <depend project="jdk" type="command" id="java" runtime="true" />
>   <depend project="jdk" type="command" id="javac" runtime="true" />
> 
>   <!-- provides -->
>   <command id="ant" path="[self.home]/build/bin/ant"/>
> </project>
> 
> Note this is just an RT. The [] syntax in there is another thing I've been
> thinking about: using EZT (a python template engine) to provide access to
> stuff inside the pythonified object model. Which is another RT.
> 
> Currently we're java-specific and CLASSPATH-specific about what kinds of
> dependencies we support. I'm not sure yet what it all /should/ look like,
> but I hope you agree we have work to do here :-D

I like!

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message