incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Debian/Ubuntu build system based on ANT
Date Tue, 12 Jun 2012 17:36:42 GMT
I'm not familiar with packaging in unix so I'm just going to comment on some principles.  I
wrote the first version of the ant build.  I thought it is important to keep compilation steps
and packaging steps separate.  Originally I envisioned that build.xml really just compiles
while packaging can be done by various tools that gather the binaries from the directory build.xml
places the binaries.  For example, package.xml can package the binaries into war and zip files
that can be dropped into an existing tomcat directory for developers who don't want to deal
with rpms just to test their code and then something else can package the binaries into rpms
and something else can package the binaries into debian packages.

Today the build system is a little muddled because the agent code that goes onto the system
vms need to be packaged itself.  We should consider that part of the compilation rather than
packaging because we're not packaging for different systems when it comes to the system vms.
 It's only debian because system is debian.  However the entire product's packaging should
be separated out and we can use appropriate tools for each type of package.  Hope that makes
sense.

--Alex

> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: Tuesday, June 12, 2012 9:52 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Debian/Ubuntu build system based on ANT
> 
> Hi,
> 
> On 06/12/2012 12:59 PM, Robert Schweikert wrote:
> > Hi,
> >
> > Let me prefix the message with the disclaimer that I am not much of an
> > expert on building Java code...
> >
> > On 06/12/2012 06:24 AM, Wido den Hollander wrote:
> >> Hi,
> >>
> >> I've been working the last couple of days on rebuilding the
> >> Debian/Ubuntu build system and getting rid of WAF.
> >>
> >> I think it got to a state where it's ready to be tested by other users.
> >>
> >> The code can be found at Github [0] under my user "wido".
> >>
> >> The goals I had were:
> >> * Get rid of WAF
> >> * Do everything with ANT
> >
> > These are generic and should not be distribution dependent. I am not
> > partial to any given build system, however, given that Ant is probably
> > the predominant way to build Java code this make sense.
> >
> 
> Since CS itself is already being build by Ant it seems logical to me to do the
> packaging also with Ant.
> 
> >> * Get the packages working under Debian as well
> >> * Get the build dependencies in order
> >>
> >> Seems it worked and my packages are now building like they are
> >> supposed to. I haven't been able to find issues at the moment, while
> >> this will of course need more testing.
> >>
> >> For cloud-daemonize I've written a separate ANT task which uses
> >> contrib-cpp [1]. For the Debian packages I've made the package
> >> "ant-contrib-cpptasks" a build dependency.
> >>
> >> This build code could be shared with the RPM build process as well,
> >> so we might want to move some targets around or make them more
> generic.
> >>
> >> I think that a great goal for CloudStack 4.0 would be to support:
> >> - Ubuntu 10.04 LTS
> >> - Ubuntu 12.04 LTS
> >> - Debian 6 Squeeze
> >>
> >> The packages will probably work on Ubuntu 11.X as well, but we should
> >> probably target the LTS versions and anything else that works is great?
> >>
> >> I'd like to get some feedback on this build system.
> >
> > I have only taken a brief look at this, and again I am not an expert
> > on creating descriptions for Ant. It appears to me that a lot of stuff
> > is now tied to debian that maybe shouldn't be. For example, the class
> > path setup should be generic, yet in
> >
> https://github.com/wido/CloudStack/commit/ef7c561f022fb88babf2d914b0a
> c
> > 57d70c5dfb1e everything appears to be tied to debian.
> >
> 
> Yes, that is true. The classpath generation was something I'm a bit stuck on.
> 
> The problem is scripts like "agent-runner" [0], they require the classpath to
> be hardcoded in them. It's a token which needs to be replaced.
> 
> Right now this is hardcoded in WAF [1].
> 
> So yes, I'm looking for the most elegant way to keep this compatible
> between various distros.
> 
> I also think the classpaths aren't correct, but I've taken them from WAF.
> 
> The agent seems to be running with much more .jar files in it's classpath then
> needed.
> 
> We will probably repackage everything if the proposal from Alex comes
> through.
> 
> > One would think that from a perspective of a packager one would just
> > have to run
> >
> > ant SOME_ARGUMENTS build
> >
> > and
> >
> > ant SOME_ARGUMENTS install
> >
> > The SOME_ARGUMENTS parts are then left up to the packager on each
> > distribution.
> >
> > I am probably missing something, sorry if my concerns are in left field.
> >
> 
> A lot of properties are now stored in "debian.properties", but we can also
> pass them runtime.
> 
> Problem is, we have a lot of properties, so that would be a lot of arguments
> to ant.
> 
> Wido
> 
> [0]:
> https://github.com/wido/CloudStack/blob/master/agent/libexec/agent-
> runner.in
> [1]:
> https://github.com/wido/CloudStack/blob/master/wscript_configure#L22
> 
> > Later,
> > Robert
> >
> >

Mime
View raw message