glest package - an analysis

[Eddy Petrişor]

On 21/09/06, Giuseppe Borzi <gborzi1 at alice.it> wrote:
> Hello Eddy,
> sorry for the delay in the answer, I had been busy with my work.

No problem, I've been busy doing the 'big endian compatibility patch'

> > Nice, I guess we could build that after we make glest work properly.
>
> Ok, I have (re)downloaded glest editor sources from sourceforge CVS.
> They are 10 months old (i.e. they are the same files I made the patch
> for), so the patch should apply without problems.
>
> >
> > :-) Heh, the changes in SVN are only the parts which diverge from the
> > original package, thus the debian directory will always be there while I
> > chose to modify immediately at source package unpacking. In other words,
> > the part in SVN will overwrite the unpacked orig tarball. It is meant to
> > be handled via svn-buildpackage[0].
> >
> > I have added that rule, but the main issue is that the package must be
> > configured in order to have the clean rule available, so now the clean
> > target depends on the configure target.
>
> Now I understand. I got confused looking at the original package and at
> your modifications with meld. GUI are not always so intuitive.

you should take a look at
http://wiki.debian.org/Games/Development/BuildProcess, I've just added
as an example what it takes to build the glest package from our SVN.

The data package will be imported at a later time. It built fine from
your last sources from REVU.

BTW, have you checked all the copyrights for the  data package? What
about the game package?

> > Second major change was to bootstrap the package (autotools) statically,
> > and not during the build process. This *is* a good thing because the
> > autotools might be broken on some arches, also there are lots of subtle
> > issues (see Sam Hocevar's talk on autotools during the Debian QA meeting
> > in Darmstaadt[1]) which are avoided this way.
>
> Thanks, that presentation was revealing. BTW, before knowing it, I was
> thinking about the following problem for glest or any other package
> using automake. I put automake 1.9 among the Build-depends and obviously
> on my system it is the default automake to be used. What can happen if
> someone with automake 1.9 and automake 1.x (x != 9) installed, but with
> the default automake to use set to 1.x, tries to rebuild the package
> from source ? There won't be an error message about a missing
> requirement (that should be "your automake alternative must be 1.9") and
> the compilation can go wrong.

Yes, that could be, but:
1) this happens for people building the package from source, so the
user is there to fix it ;-)
2) the package should be build on build machines with the correct deps
and versions.

> > [after looking at the console] YAY! The package just built in the chroot
> > (and a small change in the debian/rules file) GREAT!
>
> OK. I'll try it after putting "edgy" instead of "UNRELEASED" in changelog.

It should build just fine without doing that, but is necessary to be
uploaded officially ;-)

> > Sure :-)
> >
> > http://wiki.debian.org/Subversion and
> > http://wiki.debian.org/SmallSVNTutorial
>
> Thanks, after reading the Small tutorial I realized I need to read the
> manual.

just for building glest, it should be enough to just type the relevant
section from http://wiki.debian.org/Games/Development/BuildProcess ;-)

-- 
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein