Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Update Windows Build Instructions

From: Ed Beroset <beroset@xxxxxxxxxxxxxx>
Date: Mon, 5 Jan 2015 15:34:16 -0500 (GMT-05:00)
Stephen Fisher wrote:
>
>> Yes, use CMake :-)
>> 
>> There are other cross-platform build solutions such as SCons, but it's 
>> just as bad as CMake (or maybe worse, I haven't tried anything other 
>> than a toy project).
>>
>> Adding a dissector to CMake is as simple as it is for nmake with the 
>> bonus that it works for both Windows and Linux (and wherever else 
>> CMake is used).  Doing anything else with the CMake build system 
>> requires a lot of head scratching as getting the required output from 
>> the arcane language of CMake files can be a battle.
>
>With such a glowing review as that.. I'm not sure I want to try CMake :)  
>Perhaps it would be better to handle the different platform build 
>methods ourselves.

Having been around this particular block a couple of times, yes, CMake at times is a battle, but it's also better than the alternative of producing (and maintaining) multiple mutually incompatible and inevitably arbitrarily different build systems in parallel.

>> msbuild will also use multiple threads to build so is can be much 
>> quicker.  The other big advantage of VS solution files is that it 
>> should make it easier for folks to use the IDE debugger.
>
>Indeed.  So what about making a script to read in Makefile.common and 
>spitting out those XML files for msbuild?  Or update the msbuild so IDE 
>things in those files (if any) aren't reset every time its rebuilt.

It sounds like reinventing a subset of CMake.  I've found that for most things (the straightforward part of a makefile that typically makes up 80% of a project's build instructions) CMake works pretty well without a lot of thought.  For the other parts, there's usually only pain in figuring it out the first time, but after that, the vagaries of changes to the target systems (e.g. changes to nmake or gnu make or default locations for libraries on BSD, or any of a hundred other details) are all handled by the CMake developers.

Sorry this sounds like a "sales pitch" -- I've just done this exercise enough times to appreciate that while it's not perfect by a long shot and is maddening when it doesn't work, but even with its flaws, it's better than the alternatives I've found.

Ed