-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 26 Nov 2008 18:54:12 +0100
Jan Pazdziora <[EMAIL PROTECTED]> wrote:

> On Tue, Nov 25, 2008 at 04:14:32PM -0500, Jesus M. Rodriguez wrote:
> >>
> >> I'll appreciate if you try the new code and if you tell me your
> >> thoughts.
> >
> > How does this compare to the build.py stuff we added?
> > While I prefer the build.py (as I can work more easily with python
> > than make), I don't care which one ultimately we choose.
> 
> If I'm not mistaken, Makefile.git is still the code we use. At least
> that's what the wiki suggests to do if you want to (for example) get
> .src.rpm from the repository. The changes I've committed this week
> were long in my oven, and the primary drive was to do even old builds
> right, by observing (for example) the NO_TAR_GZ at the correct time.

Yes still the solution we use but as you know I've been tasked with
adding some substantial functionality for Satellite builds. I had a
very hard time deciphering the original Makefile.git, the new version
has improved quite a bit but still quite daunting to dive into
particularly if you're not skilled with shell/awk/perl syntax.
Meanwhile pybuild is rapidly approaching the same level of
functionality so I'm planning to proceed with that solution.

Aside from solving my own need to get something I can work with
quickly, I'm hopeful that Python scripts will serve to be easier for
the team at large to read/digest/modify going forward, and we won't
end up in a situation where only one or two people are capable of
maintaining them. Scripting language should give us a healthy array of
tools for organizing the code.

I'm not happy to advocate that we drop Makefile.git, we needed 
a solution for build tools and you stepped up and gave us one solving a
lot of the hard problems in the process. (note that I'm re-using much of
your solutions just with different glue) I just want to solve the
problem with the best technical solution we can for the long term.


> 
> The Makefile.git was modelled after Makefile.svn, which was a thing
> which allowed me to do 5.2.0, and which was inspired by dist-cvs.
> I've picked make and Makefile primarily because dist-cvs uses that,
> to be as compatible as possible with what you have in brew and koji.
> (Otherwise I'd just hack it in Perl. :-P )

Will we be headed for some issues if we were to someday be building in
Fedora Koji and are using Python build scripts? My understanding is you
generally import srpms or tarballs into Fedora CVS which we would have
previously built with our own build tools so I wasn't aware of any
areas where we'd get into trouble there previously. Please let me know
if there are.

> 
> I consider rewriting Makefile.git into build.py a bad idea -- it
> just brings another language into the mix, it puts code to packages'
> directories where the Makefile generally only has variable
> definitions, plus it will take some time to stabilize. The main
> concern that Devan had with Makefile.git, the readability of the
> code, has hopefully been addressed with the last versions of
> Makefile.git.

build.py should not plant any significant amount of code in the project
directories, it will be using code defined in rel-eng just as the
project Makefiles do today. While it is executable I would argue it
really is just configuration as well, defining a class to be used to
build the package. You could plug more code there if needed (if perhaps
a package required massive hackery to build, but this situation hasn't
arisen yet) but you could do the same with the Makefiles. It really is
no different.

Complicated Makefile:

NAME := perl-DateTime-Locale
NO_TAR_GZ = 1
SPECFILE = $(NAME).spec
include ../../../rel-eng/Makefile.git

Complicated build.py:

import sys
sys.path.append("../../../rel-eng/pybuilder/")
from pybuilder import main, TarGzBuilder
if __name__ == "__main__":
    main(builder_class=TarGzBuilder)


> 
> However, if build.py is what you guys want and what you guys will
> develop and maintain, so be it. Just put the info to the wiki and
> I'll switch to using that. Until that happens, I'm ready to
> maintain and improve Makefile.git.

Will do. II will update wiki and drop build.py's in appropriate places
as soon as I feel it's ready.

Cheers,

Devan


- -- 
Devan Goodwin <[EMAIL PROTECTED]>
Software Engineer - Spacewalk / RHN Satellite
Halifax, Canada            650.567.9039x79267
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkuq+8ACgkQAyHWaPV9my6dpACgghgy3jFKSlaQ7dU7B0SHnOha
vf0AnjPwdHFbjWw73LcrQjPRw985OTE0
=n+al
-----END PGP SIGNATURE-----

_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to