[HTCondor-devel] Problems building htcondor on Windows

["Rowe, Thomas" <rowet@xxxxxxxxxx>]

I am trying to build HTCondor on Windows 7 and having a few problems. I have MSYS (for the awk, bison, patch, and 'cp' build step dependencies) and CMake 3.4.1 installed and to all appearances all dependencies are satisfied. I am using Visual Studio 10 for the compiler.

#1) The PCRE 7.6 external bundle downloads and builds fine, but the rest of the components can't find it. I think the "install" step is broken somehow? I get many compiler errors:
    > c:\tmp\condor-8.4.2\src\condor_utils\Regex.h(29): fatal error C1083: Cannot open include file: 'pcre.h': No such file or directory
If things proceeded I'm pretty sure I'd get linker errors, too. I'm not really familiar with CMake so it's not obvious to me what is wrong.

#2) The build system re-downloads and re-compiles some "externals" bundles on every build. Every time you hit F7 in Visual Studio boost is downloaded and rebuilt, which takes forever. I can't see any obvious mechanisms that are supposed to prevent recompilation. Is this understood? There are no errors when building, but this is extremely annoying. Also, I think you have to rework the build system to even work at all without an internet connection. Is this correct? My plan is to build the system and debug it on an air gapped network (no internet).

#3) There's an error about redefining memset. I don't understand why the redefinition exists, actually. The stock function should be fine. Easily fixed, but is nobody else hitting this when trying to build on Windows?
    ..\..\..\condor-8.4.2\src\condor_tests\sleep.cpp(127): error C2169: 'memset' : intrinsic function, cannot be defined

Can anyone report building HtCondor from scratch on Windows with CMake and Visual Studio without error? Is there something obvious I'm missing? How exactly is the build system that produces the Windows installer set up? I see VS2012 mentioned on the Wiki and I'm using VS2010, but I don't see how any of these issues relate to the compiler version.

------
BTW, Is there a reason to not rip out the PCRE dependency and just do the matching with C++11 regex? If I spent some hours making a patch to do this would it be accepted? None of the "perl compatible" features are actually used and it looks to be a simple port of a couple dozen lines.

Similarly, with regard to Boost from a quick glance all that seems to be in use are Boost's smart pointers and the Python bindings. It would probably be best to simply replace the Boost smart pointers with C++11 smart pointers. Then the build system should have zero Boost dependency unless the Python bindings are enabled. Would such a patch be accepted?