On 07/06/2012 01:31 PM, David Nalley wrote:
On Fri, Jul 6, 2012 at 1:07 PM, Robert Schweikert <rjsch...@suse.com> 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.
http://www.apache.org/legal/3party.html#options
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
ouch.....
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
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
