At 13:01 2002-08-05, you wrote:
>On Mon, 2002-08-05 at 07:40, Mats Nilsson wrote:
> > The trouble of doing a combination of 'svn info' and 'sed' to patch the
> > source code as a build step, is that svn will not recognize these changes
> > as simple keyword substitutions. It will think that the file has changed,
> > even though it hasn't (in a logical sense), and the file will get checked
> > in in a changed state, upset merges and diffs and whatnot.
>
>For what it's worth, I'm perfectly happy with the file being generated
>from a script as part of my source-release procedure. This is what
>happens with your ./configure script, after all - when you create the
>source release, you run autoconf/automake/etc to create it. The file
>need not be placed in the svn repository at all, just as ./configure
>isn't.
While this is fine in performing work in a single homogenous environment
I'm concerned about:
1. Building directly from an 'svn export'ed distro. ./configure will
not have access to 'svn info'. If the file is in source control and
is checked out with correct version info, then the build process on a
remote machine wouldn't have to guess ;) what version number to write
in the source file.
2. cross platform development - finding a simple solution that works both
from a *nix Makefile as well as in a MSVC environment. Having read the
svn dev list for a while, I know that the build process on svn itself
has presented some interesting hurdles related to keeping the MSVC part
up and running. Maintaining different sets of tools/scripts is always
more difficult than maintaining one set.
3. Users on MSVC that are used to check out the source and fire up their
IDE. Even if it is acceptable to have a build script for the nightly
test environment or release preparation environment, the stuff must
still build without extra tool invocations for average joe. Therefore
I'd prefer to have a default version.h checked in, which may or may not
be updated automagically by svn or other tools.
4. Keeping the version.h file up to date when 'svn up'. I understand
that it can be tricky to implement this in svn. But it will surely
become even more tricky to implement this outside svn. And it needs
to be implemented for each project that would use this.
5. Those who think I'm insane wanting a $WorkingRev$, but still considers
extracting the $LatestChangedRev$ from the project directory and piping
this into version.h. I'm concerned that they will run into related
problems these problems too.
Thanks for your time.
Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 15:43:19 2002