dslinux/lib/flnx CHANGES COPYING ChangeLog Makefile config.h

Stefan Sperling stsp at stsp.in-berlin.de
Fri Aug 25 16:23:06 CEST 2006

On Fri, Aug 25, 2006 at 03:40:39PM +0200, Amadeus wrote:
> > here comes the magic:
> > 	* checkout head branch
> > 	* have cvs merge all new code form flnx_branch
> > 	  into head *almost automatically*.
> How, if I break Makefiles and directory structures to fit it into the 
> uCLinux build system? This is the major point here - and maybe it's 
> doable with SVN which can trace moved files. But CVS?

Mmmmh. Changing directory structure is not possible in CVS as is,
of course. But I don't think svn could merge upstream sources
that have a different directory structure as the modified sources

I agree, this is indeed a special problem that has not been
dealt with before. We should try to find a solution.
> And what if I have extracted a list of files from a Makefile and 
> inserted it into another file? Can CVS patch my target file if the list 
> of files in the original is extended?

No, the list needs to be maintained manually.
It's two seperate files after all :(

Version control systems are not that intelligent, since they
have idea about the semantics of content of files.

> There is the a version number in the changelog, but I would prefer to 
> store the original version in a separate directory (tree).

This is what the BSD people are doing in their CVS. They have a special
contrib/ directory in their tree, and Makefiles somewhere else that
use sources in contrib/ to build the software. For example, sendmail
sources are in contrib/sendmail, and the sendmail Makefile is in
usr.sbin/sendmail/. That Makefile is the "glue" to fit sendmail into
their build system.

I would suggest we use similar "glue" here.

What about the following:

	  We store unmodified flnx sources in lib/flnx/src/
	  A third party branch is relatively useless here
	  since that directory is never changed except
	  when a new version is imported. So the files in
	  this directory may be on head, and the branching
	  concept can be ignored since it it not necessary
	  in this special case.

	  We have a Makefile in lib/flnx that
	   * creates the directory structure needed for the
	     build by symlinking/copying/whatever from
	     lib/flnx/src into lib/flnx/build
	   * patches the files if needed, or copies modified
	     versions of files over origninals as already done
	     with the files in toolchain/8bit
	   * builds the library

	  Important points to keep in mind here:
	  * Any of the generated/symlinked/copied files in the build/
	    directory never go into CVS. In fact, not even the build/
	    directory itself should go in CVS - the Makefile should
	    create it dynamically.
	  * Patches or other files needed can be stored in directories
	    called patches/ or whatever makes sense.
	  * Files in src/ should _never_ be changed in place to prevent
	    accidental commits of these changes.

This way, changes to the directory structure are documented
in the Makefile - it's not ideal, but people can see what
is happening even years later. And since creating the directory
structure is now an automated task it is easy to adjust in the
future if necessary.

And we can import new versions with minimal fuss:
Apply a patch to new version in lib/flnx/src, and make sure
the Makefile in lib/flnx still does what it is supposed to do.

Would this work for you?

> > At a last point, consider consistency.
> This sounds good. But do you have an answer to my problem?

Well, once directories are being moved the whole branching
concepts falls down of course :(

But if we agree on something else for this case, and
it is documented somewhere, it's OK. I will document
whatever we come up with at the end of this discussion
in the wiki.

http://stsp.in-berlin.de                                 PGP Key: 0xF59D25F0

More information about the dslinux-devel mailing list