cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Schweikert <>
Subject Re: [DISCUSS] tools directory
Date Fri, 06 Jul 2012 18:10:09 GMT
On 07/06/2012 01:31 PM, David Nalley wrote:
> On Fri, Jul 6, 2012 at 1:07 PM, Robert Schweikert <> wrote:
>> On 07/06/2012 12:54 PM, Kevin Kluge wrote:
>>> I understood GCC to have a AL 2.0 license and to be used by the UI, as
>>> described in [1].   So it should at least be acceptable per license.   I
>>> don't see why it has to be kept in the source tree but a removal of it
>>> should also include build changes to download a known-stable version for use
>>> in the build,
>> Downloading things during build will not work in all cases, thus a "download
>> something to build the stack" is not a good option.
>> Things in the source tree should be either in source format or describable
>> as an dependency. If a "download it automatically" feature is needed for
>> developer convenience then it should be an explicit feature that can be
>> enabled.
>> I am thinking here primarily of package build systems such as OBS (Open
>> Build Service) that do not provide network access when packages are being
>> built.
> If it's a dependency, can we just move it to the deps directory?

I would prefer not to have a deps directory. From my point of view 
anything the code (source) depends on falls into two buckets.

1.) Functionality provided in another source file that is part of the 
code base.

2.) Functionality provided by some code external to the project.

Handling of stuff that falls into bucket 1 is pretty straight forward as 
it is under the control of the project, although even here dependencies 
can be tricky to manage. Everything else that falls into bucket 2 is 
external to the project and should be treated as such, i.e. keep it out 
of the tree and document the dependency. The documented dependencies 
fall into 2 categories:

a.) build dependencies; such as ant and other tools
b.) run dependencies (a runtime dependency may also be a build
                       time dependency); such as libvirt-java

 From a distribution perspective everything that falls into the 
dependency category can and should be provided as a package. This in the 
end is the packagers responsibility and not the responsibility of the 
project. There's another angle to this for developers I agree, more on 
this below.

Part of my issue as new-comer to the project and trying to get decent 
quality packages for SUSE is that things are mingled together and there 
are layered build systems, waf ontop of ant and maybe other stuff. While 
the build works, thanks to the work done for fedora by David, I am not 
really happy with this I cannot wrap my head around how things are put 
together. It would be nice to get to a point where things are clearly 
delineated and we can have a README file that clearly spells out what 
the dependencies are and how to build the various components Alex is 
working on, (avoiding the overloaded word "package" as in the distro 
context int means something different).

> Fedora's build systems are the same way.
> Moreover, while we can have a system that downloads prohibited
> dependencies, it must be a non-default option.

This is where I see the "convenience function" for developers come into 
play. For those that just what to hack on the code base and do not care 
much about how things are built etc. it is nice to have an "automated" 
way to pull in all these dependencies, ant setup-buildenv, for example 
might be a good target that could provide all these dependencies. 
However, with the dependencies out of the tree and explicitly stated it 
is also easy for packages to create -devel packages that let CloudStack 
developers install all the devel dependencies and still have them 
managed by their distro's package manager.

Yes, the implication of this is that all .jar files that are currently 
in the repository go away.

-> find . -name "*.jar" | wc
     162     162    6604


And again there are 2 options:

- the .jar file is superfluous in which case it is simple to remove
- the dependency is real and falls into a.) or b.) above, this implies
    ~ we have to document the dependency
    ~ get rid of the jar file
    ~ let developers know they are responsible for managing their
      build system accordingly.

I am not certain how this plays into the setup of the continuous 
integration server, but that should be manageable in a reasonable way.


Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead

View raw message