gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject [RT] <property/> considered messy
Date Sun, 27 Mar 2005 20:08:40 GMT
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

Cheers,

Leo



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


Mime
View raw message