>Why isn't CMake doing that by default? The convention of the target
platform should prevail over the convention of the toolchain, shouldn't it?'
CMake considers the target platform to be composed of the OS, and the
compilation toolchain. Therefore MINGW uses the 'lib' prefix.
> 2. Should I use i
I have had a boggle involving cmake that took several days to resolve. I had
originally testing Fortran code with modules (and submodules) using gfortran
exclusively. This used a directory structure roughly of the form
…/source/CMakeCache.txt
…/source/CMakeFiles/*
…/source/CmakeLists.txt
…/sourc
CMAKE 3.12.0-rc3 claims to be able to handle Fortran submodules, and my limited
testing of it suggest that it is doing an adequate job. One minor “feature”
however is that make clean with the generated Makefile does not remove
generated *.smod files. While their presence does not affect subseque
Nice Job! I've spent an inordinate amount of time helping folks come
up to speed on some of the darker corners of CMake the last few years
and it's great to have something to point to rather than my
hodge-podge of collected notes.
On Tue, Jul 10, 2018 at 8:11 AM, Craig Scott wrote:
> Hi all, plea
Hi all, please forgive the shameless self-promotion, but I figured this is
the right community of people to inform. ;)
I've just released a new book which aims to fill the gap for those wanting
to learn CMake and its latest best practices. Hopefully this is helpful for
those of you wanting a more
Hello,
some projects I am working on are built using CMake and MinGW on
Windows. It works fine, unfortunately there are come inconsistencies
regarding the names of the generated libraries. Some are prefixed with
"lib" like on Unix systems, some are not, like usual on Windows.
It seems that t
