These instructions show how to build SVK from source using Visual Studio 2005 for Win32. This guide is a result of a lengthy trial-and-error approach and there might be an easier way. Furthermore, some parts of the guide might become unneccessary in the future. So feel free to fix/enhance this page as needed.
- Download ActivePerl and install it somewhere. To be sure, do not use 'Program Files' or any directory containing spaces (?).
- Download Subversion Perl bindings from http://subversion.tigris.org/downloads/svn-win32-1.4.2_pl.zip and dump them to the proper place in your perl directory.
The following steps are probably neccessary; if skipped, windows will report a missing msvcr80.dll import each time a module is used, and the module will probably fail to load, breaking everything in the process. (for details, go to ExtUtils bugtracker)
@@ -342,4 +342,5 @@
.q{$(MYEXTLIB) $(PERL_ARCHIVE) $(LDLOADLIBS) -def:$(EXPORT_LIST)});
}
+ push @m, 'mt.exe -manifest $@.manifest -outputresource:$@;2';
push @m, ' $(CHMOD) $(PERM_RWX) $@
- Run the visual studio 2005 command prompt to initialize the build environment.
- Type "cpan", and in the cpan console type "install ExtUtils::MakeMaker" and answer yes to any dependency request. We are doing this step first because MM is a svk dependency so it will get installed sooner or later, and when it does it will overwrite our patch. This way we have more control over it. Afterwards re-apply that patch to the new MM_Win32.pm version (finding the proper spot to add the code should be easy enough). Then "exit" the console.
- Go to the directory where you have your svk 'installation' package, type "perl makefile.pl" and answer the questions (usually the defaults are ok). You should now have a new file called 'Makefile'.
- Type "nmake", which will start a lengthy download/build/test/install process. Let it run and answer any requests for dependencies.
When building several C-code modules, perl said something like "Error, can't overwrite file because it is already being used by another process; renaming to dll.AAA and scheduling overwrite at next system restart" (this is a windows problem, unix unloads the file and keeps working). To play it safe, I hit ctrl+c, rebooted and re-ran nmake each time I noticed something like that, but maybe it's not needed if perl is intelligent enough to start using the new dlls instead of the old ones.