Re: [Bug-gama] CMake Integration

[Aleš Čepek]

Petra, I am rather sceptical about MinGW, how will it survive in the competition with bash terminal offering full Ubuntu in Windows 10? This week I received a letter from a colleague from Vienna university who succeeded with installing sqltutor in the Windows bash environment.

But surely Vasileios has a point (more than a one I guess). I am planning to write down a short summary of pros and cons.

Aleš

On Mon, 21 Oct 2019 at 18:09, Petra Millarova <address@hidden> wrote:

Hi everyone! 
First of all, thank you for the contributions Vasileios! You have a valid point in the fact that using one build system would be better than two. After some research, it seems that Visual Studio actually started to support MinGW - at least to some extent.  (https://devblogs.microsoft.com/cppblog/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/) I plan on trying it out later this week, I will let you know what I have found out, I think it might be good to use autotools only if there were no major problems with it in VS, it would certainly make it simpler. 

P.

On Sun, 20 Oct 2019 at 20:04, Greg Troxel <address@hidden> wrote:

I should explain one of my comments further.

In auto*, the notion is that the configure code should test for a
feature, such as a library existing, or a header, or if some sample code
can be compiled.  None of this should ask "what OS am I on", so that
when it's built on a not previously contemplated OS, it just works.

cmake may have the same notion.    But almost always when I deal with
packages that have cmake build systems and that do not actually build (on
the system I am building them on), I see a lot of conditionals about OS
type.

So I'd say that if the cmake code has "if this is a mac, do X", or
similar, that's a bug and should be removed, in favor of a feature test.

Of course, another view is that the cmake build should be only for
windows, in which case

if this os is not windows
  throw an error

is a good approach.