Frank Warmerdam wrote:
>> users who build from source may not have SWIG, and may not want to
>> install something that's not used at runtime but only for compilation.
>
> this sounds like a no-brainer to me. If a user wants to build from
> source, then they need to install the required -dev tools. end of story.
Hamish,
I disagree that it is a no-brainer. It is a reasonable strategy to
decide to commit some intermediate files (such as bison, flex, autoconf,
and swig output) in order to make it less complicated for developers to
build from source.
Committing intermediate files makes it more less complicated for end
users to build from source, but *more* complicated for *developers*.
If you just check out the source, then configure, make, make install,
having the generated files reduces the number of tools required.
However, if you want actually change any of the source files from
which the intermediate files are generated, then having the
intermediate files in SVN complicates matters, e.g. requiring you to
commit the intermediate files whenever the source files are changed.
[You also need to commit the complete chain of intermediate files if
you want to write Makefile rules which actually handle both cases.]
This causes problems if someone forgets to commit the intermediate
files, and can add a lot of noise to the change history if multiple
developers have even slightly different versions of the tools.
There's also the issue that most version control systems set local
timestamps according to checkout/revert/etc, not commit.
It can be very challenging for new developers to get just the right
versions of all these things for one package, much less many. For
instance, GDAL only works for a very narrow band of swig versions.
Other packages might only work with incompatible versions. If most
developers aren't actually changing the swig generated files, while
force them to wrestle with versions for all these tools?
Well, the obvious reason, as you suggest is that keeping intermediate
files in source control can result out of date versions being used
as well as "source control churn".
All I would ask is that the project make a deliberate decision on
this, not just assume the answer is cut and dried.
My view is that the SVN repository exists for *developers*, who will
modify source files, commit changes, perform incremental compilation,
etc. From that perspective, keeping intermediate files in the
repository is a net loss.
Keeping intermediate files in a source tarball is a different matter.
We can assume either that the user won't make changes, or that changes
will be sufficiently uncommon that requiring recompilation from
scratch (make distclean) isn't a problem. Also, any changes won't be
committed directly to SVN.
I, for one, have been driven away from contribution to some packages
exactly because I could never seem to get and keep just the right
versions of various things. I find this especially annoying with
autoconf.
I understand that problem quite well. Generally, I'll try to avoid
unnecessary depdencies altogether, but that isn't a practical option
for SWIG. We don't use automake etc (which tend to be much worse than
autoconf for version issues). By sticking with autoconf 2.13, we've
avoided the frequent updates to the later autoconf versions (Gentoo
has two separate slots for autoconf, one for 2.13 and one for all of
the newer versions).
Also, any barriers to modifying the configure script aren't
necessarily a bad thing. If someone breaks the configure script, they
break the whole of GRASS, so it's not entirely a bad thing if
developers (particularly those who don't do a lot of autoconf) need to
post configure.in diffs to the list rather than just commiting the
changes themselves.
--
Glynn Clements <glynn@gclements.plus.com>