On Wed, Oct 17, 2012 at 12:50 PM, Edison Su <edison...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Noa Resare [mailto:n...@spotify.com]
>> Sent: Wednesday, October 17, 2012 8:15 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: what is the plan for the build system?
>>
>> On Wed, Oct 17, 2012 at 11:07 AM, Wido den Hollander <w...@widodh.nl>
>> wrote:
>>
>> > The work I done on the Debian packages makes sure they work on Ubuntu
>> > 12.04 and on Debian Unstable.
>>
>>
>> I think that is perfectly reasonable. If we determine that it is a
>> viable
>> solution to backport what is needed to Debian Squeeze I will do my best
>> to
>> convince my organization to make those packages available to the
>> community.
>>
>>
>> > * What is the long term plan for the build system? Right now we use
>> Make
>> >> (debian/rules), waf, maven and ant and that setup doesn't exactly
>> lend
>> >> itself to a gentle learning curve. Also, it builds everything (at
>> least)
>> >> twice.
>> >>
>> >>
>> > This hasn't been decided yet in total, but my idea would be (deb):
>> >
>> > * dpkg (debian/rules) calls maven with sbindir, sysconfdir args, etc
>> > * maven outputs a completely build tree in build/usr/sbin,
>> > build/etc/cloud, etc, etc
>> > * dpkg then fetches the files from build/* into the required packages.
>> >
>> >
>> >
>> I agree that having debian/rules call maven that in turn builds the
>> packages would be the cleanest way.
>
> For RPM build, what Hugo did is that:
> 1. "maven install" will install everything into target folder under each
> project
> 2. write a rpm spec file to pick up artifacts from all of these target
> folders, e,g:
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=packaging/centos63/cloud.spec;h=b0f4046fef53dd302d1cdecd3db97bffb8357000;hb=4b079cd3dd1304272bbeb61b38c2a10c6715203c
>
> Can the same thing be done for deb build? I think this is the cleanest way,
> rpm/deb build is decoupled from maven or ant, or whatever java build we will
> use.
Personal opinion here.
I think both approaches are good, but not ideal.
Ideally in my mind - maven install (or some similar profile) would
actually deploy the software to the machine you are on. Configurable
arguments for things like bindir, sysconfdir, and prefix (default
being /) (and perhaps on a per-project basis). And that should become
the default way for developers to deploy CloudStack (with a remote
option that pushes software to a remote machine/devcloud)
Having different install/deploy methods for developers and users is
fail - everyone should be using the same thing - which will eliminate
many of the differences.
Packaging tools like rpmbuild/dpkg should call something like mvn
install -Dprefix=%{buildroot} and be able to walk away with packages
that would deliver something nearly identical (but better, because
it's a package) as running mvn install on a machine.
Thoughts, comments, flames?
--David
