[OpenSER-Devel] SF.net SVN: openser: [2950] trunk/scripts

[Henning Westerholt]

On Saturday 20 October 2007, Dan Pascu wrote:
> Regarding this, I think the generated files should not be under version
> control and in the distributed source. It is already a real pain to keep
> them synchronized after the smallest change and also make sure that
> running make proper always returns the tree to its initial state.
>
> Experience shows that autogenerated files that are put under version
> control and distributed with the source are a source of trouble.
>
> We should either remove them from the source (considering that they are
> built again everytime make is run, there is not much need to keep them
> around), or we should stop building them automatically everytime make is
> run and instead make a Makefile entry to build them only on demand.
> I would personally prefer the former solution.

Hello Dan,

first of all thank you for your fixes in the db files, there really 
appreciated.

Originally the autogenerated files are not included in the repository. Daniel 
asked my to include them because of the xsltproc dependencies. He want to 
avoid on building. This is the same reason we include the README files in the 
repository as well.

> Here are just 2 examples of how things can go wrong:
>
> 1. If the automatically generated output differs at all between developers
> (assume my xsltproc generates the output a bit different from yours),
> then we will keep overwriting each others version of the files in svn
> everytime we commit something.

This happens already with the README files on my machine. My docbook2txt uses 
a different line length, so many files are wrapped differently, and i must 
fix them before commiting..

> 2. Assume you want to build a debian package, but need an altered db
> schema. You use dpatch to create a patch that modifies the xml schema and
> build the package. But now, the generated files will also be different
> and after a make proper they won't be returned to the original state
> which means that the debian diff will be broken if you build it again.
> Now one could include the modifications to the generated files in the
> debian patch as well (but this is pretty much an ugly hack as it assumes
> that the generated files and their counterparts resulted from patching
> are identical). One shouldn't patch files that are generated as a result
> of the build process. If the generation tool changes the generated output
> at all, the patch will no longer be able to deapply and you will be
> required to remake the debian patch from scratch. At any rate
> maintainability of this situation is very poor and problematic.

I would prefer to not include the autogenerated files in the distribution. If 
we need them because we don't like this depencies, then we should stop 
building them automagically. This would also be consistent with the README 
files case. 

If nobody object, i'll remove the autobuilding from the debian packages later. 
For the "normal" make there already not build them.

Cheers,

Henning