Reply to message «Re: 7.3 missing File Browser ??», sent 23:19:50 07 November 2010, Sunday by Benjamin R. Haskell:
> Hmm. After `configure`, src/auto/config.mk. But after `make`, nothing
> in Vim. Must have been thinking of another project. It's still better
> advice generally to install after building, rather than running software
> out of the source directory. Vim does a better job than most,
> apparently.
Generally I agree, though it requires additional copy. When talking about vim -
not.
> I didn't say you did. I just said building and running out of the
> source dir is bad for the same reasons. And when $VIMRUNTIME is the
> source dir, it's easier to modify things within $VIMRUNTIME for
> development purposes, which is bad.
Here I do not agree: if file is modified for development purposes it is better
to keep it tracked, so having source dir as $VIMRUNTIME will enable clearer
setup for testing.
> You certainly can. The first step of the build script I use sets up a
> build directory:
>
> builddir=`mktemp -d /tmp/build-vim.XXXXXXXX`
> # Mercurial:
> hg archive -t tar -p . - | (cd $builddir ; tar -xf -)
> # Git: (I do most dev under an hg-git clone)
> git archive HEAD | (cd $builddir ; tar -xf -)
Forgot about this. You can optimize the process: mercurial can archive to
directory without using tar:
hg archive $builddir
According to the ``git help archive'', git cannot do this.
> > You do not need any setup, you just should not track new files.
> > .hgignore in vim repository already has lines that handle it.
> What would you call .hgignore if it's not 'setup'?
If make does not modify tracked files, you do not need any setup. If vim did
not
have .hgignore, the only thing you would need to do is to ignore additional
lines in `hg status'. It has - so it is good.
> Best practices while developing code involve configuring and building,
> and then installing to a directory other than the source directory. (I
> still assert that an external directory for configure+build is
> preferable, but do what you will -- .hgignore is apparently set up to
> mitigate this issue except for src/auto/config.mk). Installing to a
> directory other than the source directory allows changes to be made
> within the source directory without affecting the installed version.
> "Changes within the source directory" includes updating to the latest
> code and changing things in the source directory for development
> purposes.
If I need to ignore changes to the source directory and still install software
from SCM, I write an ebuild and let cave handle it (it is possible to create a
package without being system administrator if you want to do so). Otherwise I
do
want this changes to affect currently used version.
signature.asc
Description: This is a digitally signed message part.
