Re: Project specific settings
On Mon, May 14, 2007 at 10:11:02AM +0200, Sebastian Menge wrote: Am Montag, den 14.05.2007, 10:05 +0200 schrieb Marius Roets: I always uses spaces to indent my code, but a current project requires me to use tabs. How could I make this setting only be in effect for this one project, assuming that the project will always be a in a specific directory. :help mksession :help tabstop Of, if in a specific directory means under a directory with some specific name but possibly in many places do something like au BufNewFile,BufReadPost */projectname/*.[ch] set noet ts=8 BTW tabs suck. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
On Mon, May 14, 2007 at 02:24:09PM +0200, Bram Moolenaar wrote: This is not a bug, an empty src/auto/config.h is included, because otherwise make depend doesn't work. I would rather say this means an additional problem in the Makefiles. If a rule requires src/auto/config.h, it should create it (directly or indirectly by dependences) when it does not exist. That's what make is for. If `make distclean' can remove src/auto/config.h and create it empty, why it cannot be created [empty] by the thing that actually needs it? This indeed works strangely; for instance `make -jN' with N 1 works with freshly unpacked sources, but it breaks completely after `make distclean' -- which one would expect to get the source tree to the same state. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
(dropping [EMAIL PROTECTED] from cc) On Mon, May 14, 2007 at 07:36:30PM +0200, Bram Moolenaar wrote: This indeed works strangely; for instance `make -jN' with N 1 works with freshly unpacked sources, but it breaks completely after `make distclean' -- which one would expect to get the source tree to the same state. Well, figure out why it breaks The above report is incorrect, it just breaks always, I'm sorry. I probably run configure so automatically that I accidentally made it work. It breaks because make starts making `scratch', `config' and `myself' simultaneously. And that appears to be due to the first targets to make vim are: scratch config myself As these targets overwrite the same files with different content, it breaks one way or another. Explicite configure bootstraps the build system and thus makes -jN safe for normal compilation. and fix it... Unfortunately my view of how a build system should work is incompatible. I can tell when something breaks and hopefully I can figure out how it happens, but I have no idea what fixed means here. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
On Mon, May 14, 2007 at 11:05:24PM +0200, Bram Moolenaar wrote: Hmm, in my POV a rule like: target: one two three means that one, two and three are build in sequence, not at the same time. This means `one', `two' and `three' have to be built for `target'. More precisely any commands necessary to build any of `target's prerequisites will be fully executed before any commands necessary to build the target. The order is chosen with regard to the full dependency tree: all: a b c a: c @echo a b: @echo b c: b @echo c Single-job make has no reason to reorder the prerequisites once they are fully resolved, but AFAIK it is free to. GNU make even has a special construct to specify the order of build without implying dependency. BSD make OTOH has a `be backward compatible' option to enforce building in dependency order (it is on by default in single-job invocations). Both will give you b c a from Makefile all: a b c a: @sleep 3 @echo a b: @sleep 1 @echo b c: @sleep 2 @echo c when run with enough jobs. I suppose adding the -jN argument changes the semantics of the Makefile, and that causes it to break. If there ever was such semantics. I've yet to see a make specification that precisely defines the build order of independent targets. The Vim makefile was written for a common version of all make programs. So that it builds nearly everywhere. I'm not sure supporting -jN is possible without breaking it for some system. Or including false dependencies. Maybe, although non-working -jN often indicates missing real dependencies. Anyway, if one neither knows he cannot use -jN nor that he can run make without running configure first -- which I suppose characterizes most people -- it works. And with independent dependencies that rewrite the same file with different content it probably cannot be fixed. I know, in my view make should do everything. Somehow people have accepted that some part of the building should be done separately, with the excuse that it's called configuration. Big mistake in my opinion. There's nothing wrong on acknowledging there are inherent chicken-egg problems and breaking the cycle explicitly. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
On Sun, May 13, 2007 at 09:28:11PM +0100, [EMAIL PROTECTED] wrote: Umm, I suspect there's still an issue for us pesky OSX users with our case-insensitive filesystems: [long list of successful updates snipped] svn: Failed to add file 'src/auto/config.h': object of the same name already exists Gah. Scrub that. Manually removing the file in question and updating again has sorted it (that's the first time I've had Subversion complain over several updates). Sorry for the noise... Actually, this is a repository bug. src/auto/config.h is fully generated therefore it should not be versioned. Yeti -- http://gwyddion.net/
Re: (Doc RFE) rgb.txt
On Wed, May 09, 2007 at 09:25:09AM +0200, A.J.Mechelynck wrote: I had a devil of a time locating the rgb.txt file on my SuSE 10.2 distro. locate rgb.txt Or, if you don't have locate installed for some reason, find /usr -name rgb.txt In order to alleviate the task of fellow users, I propose the attached patch to :help rgb.txt. The file can be virtually anywehre, it is even in /etc/X11 on some systems. Yeti -- http://gwyddion.net/
