So I was just reading the cvs docs and I came across this handy chapter: 13. Tracking third-party sources
http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_13.html#SEC104
This seems to be the way that we should be tracking code that is not maintained in the pure-data.sf.net CVS. I believe guenter was talking about switching the pd sources to this method, and I think we should use this method for the externals as well.
Basically, the code from the original source is maintained in a separate branch, while we work on the MAIN branch (which is the default). Then we 'cvs import' new versions from the source into that separate branch and merge changes into the MAIN branch.
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Basically, the code from the original source is maintained in a separate branch, while we work on the MAIN branch (which is the default). Then we 'cvs import' new versions from the source into that separate branch and merge changes into the MAIN branch.
This sound cool, without having read this.
I'd like to announce another idea I had tonight while out clubbing (forgive me, if it doesn't make sense because of this...)
I wonder, if an "installer" branch would make sense. In this branch, the package maintainers could make changes that ease packaging, like for example unifying variables in Makefiles and so on. Later this could be merged to upstream.
Good idea?
ciao
On Saturday, Mar 20, 2004, at 21:47 America/New_York, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Basically, the code from the original source is maintained in a separate branch, while we work on the MAIN branch (which is the default). Then we 'cvs import' new versions from the source into that separate branch and merge changes into the MAIN branch.
This sound cool, without having read this.
I'd like to announce another idea I had tonight while out clubbing (forgive me, if it doesn't make sense because of this...)
I wonder, if an "installer" branch would make sense. In this branch, the package maintainers could make changes that ease packaging, like for example unifying variables in Makefiles and so on. Later this could be merged to upstream.
Good idea?
You think about installers while clubbing? ;) Anyway, I don't think its really necessary to have a separate branch. The installer-specific files are in their own directories and usually, the changes that I need to make when making the installers are generally helpful, ie making things easier to build, etc.
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Saturday, Mar 20, 2004, at 21:47 America/New_York, Frank Barknecht
I'd like to announce another idea I had tonight while out clubbing (forgive me, if it doesn't make sense because of this...)
I wonder, if an "installer" branch would make sense. In this branch, the package maintainers could make changes that ease packaging, like for example unifying variables in Makefiles and so on. Later this could be merged to upstream.
Good idea?
You think about installers while clubbing? ;) Anyway, I don't think its really necessary to have a separate branch. The installer-specific files are in their own directories and usually, the changes that I need to make when making the installers are generally helpful, ie making things easier to build, etc.
Actually I was thinking about packaging at home, when doing an extended Debian rules file and I found, that the flext-externals use inconsistent namings. Sometimes FLEXTPATH should point to the toplevel flext directory, sometimes if should point to flext/source, sometimes to flext/pd-linux (or similar). The idea to fix this with branching came while clubbing (loud music sometimes helps with thiso ;)
If FLEXTPATH was consistent, then the rules-file (which basically is a Makefile) could just set FLEXTPATH once and for all, but this would need changes inside the respective external directories.
ciao
Actually I was thinking about packaging at home, when doing an extended Debian rules file and I found, that the flext-externals use inconsistent namings.
Well, someday there will be a unified flext make system with perfect consistency for all platforms.... if there only were the time to do it.... or maybe someone else wants to....
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Actually I was thinking about packaging at home, when doing an extended Debian rules file and I found, that the flext-externals use inconsistent namings.
Well, someday there will be a unified flext make system with perfect consistency for all platforms.... if there only were the time to do it.... or maybe someone else wants to....
I have localized one of the problems I have when building packages. As the current Debian build-process tries to built everything in one go, there is currently no "install" of flext prior to the build of the other externals. VASP uses the variable FLEXTPATH to specify both the location of the libraries and the location of the header files. But in the flext directory both are in different places: flext/source and flext/pd-linux
In some other externals, both use different names like FLEXTINC for the header location. For building (Debian) packages this is easier to handle.
I tried this with a change to vasp/makefile.pd-linux to use FLEXTINC where header paths are used:
$(TARGDIR)/%.o : $(SRCDIR)/%.cpp $(CXX) -c $(CFLAGS) $(FLAGS) $(patsubst %,-I%,$(INCLUDES) $(FLEXTINC)) $< -o $@
And in config-pd-linux.txt I added:
# where do the flext libraries reside? FLEXTPATH=${PD}/flext
# where do the flext header reside? FLEXTINC=${PD}/flext
This now can be overridden in the toplevel package Makefile ("rules" on Debian) by things like:
(cd grill/vasp; $(MAKE) -f makefile.pd-linux FLEXTINC=../../grill/flext/source FLEXTPATH=../../grill/flext/pd-linux)
ciao
Yes, I had similar problems when building flext and its externals. I think whoever is going to make a compile for flext should probably go through the variable definitions, make them consistent and send a patch to fix that.
About splitting the packages:
In order to be able to make releases from the CVS directly, I think we would have to make separate releases for big packages like flext, cyclone, zexy, pdp. It is very unlickely that all of these will be in releasable state at the same time. (I am not insisting on that though, just think it ould make some things easier)
Guenter
On Mon, 22 Mar 2004, Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Actually I was thinking about packaging at home, when doing an extended Debian rules file and I found, that the flext-externals use inconsistent namings.
Well, someday there will be a unified flext make system with perfect consistency for all platforms.... if there only were the time to do it.... or maybe someone else wants to....
I have localized one of the problems I have when building packages. As the current Debian build-process tries to built everything in one go, there is currently no "install" of flext prior to the build of the other externals. VASP uses the variable FLEXTPATH to specify both the location of the libraries and the location of the header files. But in the flext directory both are in different places: flext/source and flext/pd-linux
In some other externals, both use different names like FLEXTINC for the header location. For building (Debian) packages this is easier to handle.
I tried this with a change to vasp/makefile.pd-linux to use FLEXTINC where header paths are used:
$(TARGDIR)/%.o : $(SRCDIR)/%.cpp $(CXX) -c $(CFLAGS) $(FLAGS) $(patsubst %,-I%,$(INCLUDES) $(FLEXTINC)) $< -o $@
And in config-pd-linux.txt I added:
# where do the flext libraries reside? FLEXTPATH=${PD}/flext
# where do the flext header reside? FLEXTINC=${PD}/flext
This now can be overridden in the toplevel package Makefile ("rules" on Debian) by things like:
(cd grill/vasp; $(MAKE) -f makefile.pd-linux FLEXTINC=../../grill/flext/source FLEXTPATH=../../grill/flext/pd-linux)
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Thomas Grill