On Sun, 7 Nov 2010, ZyX wrote:
Reply to message «Re: 7.3 missing File Browser ??»,
sent 22:06:51 07 November 2010, Sunday
by Benjamin R. Haskell:
Just because you *can* do that doesn't mean you should. This is bad
advice, especially if you want to do any development on Vim. It's
bad for the same reason modifying files under VIMRUNTIME is bad:
there are cleaner mechanisms for making local customizations. And
it's bad from a development standpoint because you end up with
modified files in the source directory that the version control
system doesn't know *should* be modified. Both of these can cause
problems when you update your source files (unless you immediately
rebuild).
Where have you seen modified files in source directory?
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.
I do not modify anything in $VIMRUNTIME,
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.
I just do not install vim anywhere.
Right, and I'm saying one should, in general.
If you are talking about files that are generated by `make', then
there are two points: 1) make does not modify any tracked files
(configure does);
Conceded above. I work on a lot of projects, and Vim's better than many
in that regard. It's also better about confining its files to the
--prefix=DIR directory.
2) you cannot install vim without building it while
inside a repository.
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 -)
In general, version control systems (in this case Mercurial) and
build systems (in this case autotools) aren't set up to cleanly
handle the case where source, build, and installation directories are
the same.
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'?
Much better is to simply specify a prefix argument when you run
`configure`, e.g.:
./configure --prefix=$HOME/myvim --whatever-other-features
It is not better because it affects only make install. But before you
install you must build it. And, surprise, configure will modify
src/auto/config.mk which is tracked.
I still assert that's broken (that src/auto/config.mk [a tracked file]
is modified, instead of a new file being created).
If you specify a directory to which you can write files, you don't
need root privileges for `make install`.
I know.
I didn't say you didn't. That was a general response. (The OP wrote
that he had run `sudo make install`)
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.
--
Best,
Ben
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
