Re: [Bug-gama] CMake Integration

[Greg Troxel]

Vasileios-Athanasios Anagnostopoulos <address@hidden>
writes:

> In general, I would advice against of having 2 build systems. This
> makes the maintenance of the project more difficult and the 2 systems
> might go out of sync eventually. Depending on what are the goals of
> the project, there are 2 alternatives that I would suggest:

The notion of not having two build systems has some merit.

However, I think it's currently out of the question to stop using
autotools.  Many times, I have seen people claim that cmake is better,
and then end up in a worse situation with less support for cross
compiling and per-OS code in the build system, not to mention needing a
huge package installed to do the build.

> * If it is preferred to use the autoconf tools, then for compiling the
> project under windows I would use the MinGW project (which also has
> support for autotools --
> http://www.mingw.org/category/wiki/autotools). The main disadvantage
> of this approach is the compatibility of the dlls. The dlls produced
> with mingw, I think (I am not 100% certain!), are not compatible with
> Visual Studio. So they can not be linked against projects that are
> being compiled with Visual Studio. Probably for these projects, a
> C-wrapper can be created, but that complicates a lot the use of the
> library. If we only want to generate the gama-local.exe, then this is
> not a problem.

This sounds reasonable to me.  I don't think accomodating non-free
toolchains is a goal, but I'm not Aleš.  My impresssion is that now, we
have auto* for POSIX systems, and cmake as an accomodation for Windows.

> * If it is preferred to move to CMake, then I would create a CMake
> configure wrapper
> (e.g. https://github.com/Richard-W/cmake-configure-wrapper and
> https://github.com/nemequ/configure-cmake). That way, the project
> would be compliant with the GNU standards. But that would introduce a
> strict external dependency for compiling the project (i.e. installing
> CMake before compiling the project). Furthermore, although technically
> we comply with the GNU guidelines, we might not be following the
> spirit of the guidelines.

I don't think that follows the guidelines.  The point in my view is to
actually use auto*, not to pretend to use it :-)

> * I can re-introduce the old libExpat. CMake can examine if there is a local 
> libExpat version, and if there is, use that instead.

I would say that your changes should be in clean changesets in the git
sense, where each commit does one logical thing.  And you should put
related things in a branch.

Arguably, if the point is to improve the cmake support, things that are
not directly related to that should not happen at all.

Greg (old-school ranter, in case you haven't noticed :-)