Re: [HTCondor-devel] Problems building htcondor on Windows

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

> On Dec 22, 2015, at 9:29 AM, Rowe, Thomas <rowet@xxxxxxxxxx> wrote:
> 
> 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).

You may want to investigate âPROPERâ mode: this relies on the host for its dependencies.  This is how Linux distributions (i.e., not upstream) tend to package condor â distros similarly want the build system to work without an internet connection.

Certainly the intent is to cache the externals - and this is what is done on Linux.  Apologies, I donât know the details here: I havenât had access to a Windows environment in several years.

> 
> #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
> 

I donât understand what sleep.cpp is used for at all.  The history indicates this is something about avoiding linking in a runtime on Windows?

Anyhow, you can probably disable the building of tests via a cmake variable (âBUILD_TESTINGâ).

> 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.

Hm - the problem with PCRE is that it is exposed via the âregexpâ and âregexpsâ functions in ClassAds.  Hence, itâs part of the âuser facing APIâ â hard to determine whether there are any users of various features.

Iâm not intimately familiar with PCRE-vs-C++11 â can the âregexpsâ function be done C++11-only?

Certainly thereâs code in the build system to detect a C++11 compiler.  Iâm sure we can at least consider patches that allow you to disable PCRE when C++11 is present.

> 
> 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? 

In many (most? all?  certainly in classads) places, this is done when a C++11 compiler is available.  If you find other places where boost isnât replaced by C++11 features when available, certainly those patches would be accepted.  I couldnât find any cases (hm - maybe C++11 detection is broken on Windows?!).

Some of the tests may depend on boost, but you can again compile them out.

Good luck!

Brian