[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 5 January 2015 at 17:35, Stephen Fisher <sfisher@xxxxxxx> wrote:

On Mon, Jan 05, 2015 at 05:20:27PM +0000, Graham Bloice 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.

It's the least worst option.  It is actively used elsewhere though.

We've handled the platform differences in the past by using make and nmake and autofoo and other piles of configuration grief.

For Makefile.common, now think of CMakeLists.txt, that bit is very simple.  Arguably CMake could be persuaded to read Makefile.common as it's just a list of files.

> I guess nmake was used in the past as a) it's nearly make, and b) the
> Visual Studio solution files at the time were horrible undocumented
> blobs that could only be read by the IDE.  Nowadays they're somewhat
> documented bloated XML blobs that can be built using msbuild (which is
> quite nice to use)

Yuck, XML.

Fortunately using CMake means that unless you're modifying the build system you'll never have to look at them.

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

Good luck with that, you're just reinventing CMake and Scons and ... . I don't think you're really aware of the scale of the problem.  Currently CMake produces 1 solution file and 310 vcxproj files.  Sure, some of those .vcxproj files are how CMake checks itself for a rebuild when invoked by msbuild, but a lot of them are necessary.

I don't get your last comment.  Unless you're modifying the build system or adding new files, CMake doesn't come into it after the initial solution generation.  The solution files automagically rebuild themselves if something in the CMakeLists has changed (i.e. a new file has been added).

The path is CMakeLists.txt -> Wireshark.sln

I don't know of any cross platform build system that will then round trip back the way.

While not the greatest tool to work with, CMake does do a good job.  The dependencies etc. are much better handled than in nmake (minimal rebuilds), it's faster (given more cores), clean is < 2 secs, and folks only need to manage one build system on all CMake platforms. 

Have you tried using CMake for Wireshark on bsd?

--

Graham Bloice