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/ef7c561f022fb88babf2d914b0ac57d70c5dfb1e
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
