Bram Moolenaar wrote:
Mathias Michaelis wrote:
Patch
Problem: IMHO .pdb files should reside in the same directory as the
corresponding .exe files so they can be distributet along
with them.
Solution: Change one line within src/Make_mvc.mak
Files: src/Make_mvc.mak
This doesn't matter for the distribution, the .pdb file can be moved
around after generating it. It might matter for when you want to run
Vim right after compiling it. I haven't tried it.
Of course: If the pdb file is created in a subdirectory OBJGO, then
you must move this directory when ever you move the corresponding
Vim .EXE file. Thus, if you have gvim, gvimd, vim and vimd in your
$VIMRUNTIME directory, you need four(!) subdirectories named
"OBJ..." there, each of them containing only one file: the
corresponding .PDB file.
Otherwise, you can't debug the executables without first guide your
debugger to the location where the corresponding .pdb file is stored.
Do you mean that the subdirectory is stored in the executable?
And yes: the .PDB are not needed for a distribution. But this is no
reason to hide these files in some subdirectories. Maybe, someone
wants to copy these files in the same $VIMRUNTIME directory as the
executable files. Or even wants to create his own distribution that
contains these files -- as Antoine Mechelynck contributed the
debugging executables vimd.exe and gvimd.exe at the times when he
compiled Vim.
This is why I plead to make this patch an official one :-)
The reason to put the .pdb file, and any other generated files, in a
subdirectory is to keep the source directory clean. And to have a
different subdirectory for the various versions.
IMHO, in the case of builds "with debugging information" (vimd.exe and
gvimd.exe), it makes sense to keep the debugging information in the same
directory as the executable, regardless of whether is is actually in the
.exe itself (as with BCC and gcc) or in an auxiliary file.
OTOH, the "non-debug" builds are supposedly distributed stripped of any
debuggig information (such as symbol tables, line numbers, etc.). For
them it makes sense to keep the generated symbols file (if any) with
pathdef.c if_perl.c *.obj etc., away from the src/ subdirectory.
Or else, change the build philosophy and have the executables end up in
$(OBJDIR) instead of in src/ itself; but that might break automated
"roll-your-own" procedures like Steve Hall's and mine; and it would also
require changes in the procedures for "make clean" "make distclean"
"make install" ...
Just my 0,02€
Tony.
