CMake -> Visual Studio: default is /MD (Multithreaded DLL)

[Greg Ercolano]

I noticed building fltk 1.4.x with cmake, it default builds FLTK in such a way
that when I build other apps against the generated FLTK.LIB, those apps must be
compiled with the /MD flag.

I get a boatload of errors if I try to build the app using /MT.

I'm creating a video showing how to build FLTK with cmake+VS 2017, and then
compile/linking a program from scratch against it.

Also, it's kinda nutty where the FL and lib files get saved; when I build my app,
I find I have to include two directories:

c:\fltk-1.4.x\ -- for the FL directory with all the usual fltk .H files
c:\fltk-1.4.x\build\ -- fot the FL directory that has the one abi-version.H file

What's the "right" thing we want here, so I can show the 'proper way' in the video:

1) Should new apps include both include dirs?
2) Should c:\fltk-1.4.x\FL\*.* files be (copied? moved?) into the build/FL?
3) Should the abi file be moved into c:\fltk-1.4.x\FL\, and remove the build/FL directory?

I don't like 1 because that's just confusing and unprecidented.
I don't like 2 because if copied, then there's two FL dirs (confusing), or if moved,
then the FL directory isn't where it traditionally should be.
Option 3 seems reasonable, as this I think is consistent with the unix builds (?),
so that there's only one FL directory.

Ditto for the generated libs. Right now there's a c:\fltk-1.4.x\lib directory, but
after a cmake/VS build all, the libs end up in "build/libs/Release/", which is confusing.

I think cmake is trying to allow us to have multiple builds using the same fltk directory,
so that apps could link against different build dirs in the same fltk directory.

But doesn't that just make everything more complicated for the users that don't need
such complexity? In the past, if people wanted multiple builds of FLTK, they'd make
separate copies of the entire FLTK directory, and build each on its own, so there's
no chance of overlap.

Is putting the resulting .H/.libs/test programs in separate build directories
really a good idea, as compared the simpler "traditional" alternative?

[Gonzalo Garramuño]

El 28/05/20 a las 20:18, Greg Ercolano escribió:

> I think cmake is trying to allow us to have multiple builds using the same fltk directory,
> so that apps could link against different build dirs in the same fltk directory.

Correct.

> But doesn't that just make everything more complicated for the users that don't need
> such complexity? In the past, if people wanted multiple builds of FLTK, they'd make
> separate copies of the entire FLTK directory, and build each on its own, so there's
> no chance of overlap.

Well, copying the whole .vcproj, .sln was a tad ugly.

> Is putting the resulting .H/.libs/test programs in separate build directories
> really a good idea, as compared the simpler "traditional" alternative?

I am not sure if the VS generator supports the install command. If so,
it doesn't matter where the build happens, but where it goes after
installation.

[Albrecht Schlosser]

On 5/29/20 1:18 AM Greg Ercolano wrote:
> I noticed building fltk 1.4.x with cmake, it default builds FLTK in such a way
> that when I build other apps against the generated FLTK.LIB, those apps must be
> compiled with the /MD flag.
>
> I get a boatload of errors if I try to build the app using /MT.

Hmm, what is the difference between /MD and /MT? Looking it up ... OK,
/MD seems to be "MultiThreadedDLL" whereas /MT is "MultiThreaded" (i.e.
static?) in CMake language.

I did a little research and found that CMake 3.15 added an option to
change the build type in VS builds, i.e. using /MD vs. /MT. Since I'm
not a VS user I wonder how useful or important this feature would be,
for instance if it's worth to add a CMake option to toggle this switch.
Both options have corresponding values for /MDd and /MTd, respectively,
for debug builds.

CMake 3.15.0 is pretty new (Jul 2019) hence we'd need a fallback method
for CMake 3.14 and older which we still support, but this is possible as
well and users report that they have been doing this in their projects
for a long time.

FTR:
https://stackoverflow.com/questions/14172856/compile-with-mt-instead-of-md-using-cmake/14172871#14172871

Question: would it be useful/important to have such an option as a FLTK
CMake build option, i.e. selectable by the user building FLTK?

> I'm creating a video showing how to build FLTK with cmake+VS 2017, and then
> compile/linking a program from scratch against it.
>
> Also, it's kinda nutty where the FL and lib files get saved; when I build my app,
> I find I have to include two directories:
>
> c:\fltk-1.4.x\ -- for the FL directory with all the usual fltk .H files
> c:\fltk-1.4.x\build\ -- fot the FL directory that has the one abi-version.H file

Yep, that's the price we're paying to be able to do full out-of-source
builds with CMake. I posted some comments on this issue in fltk.general,
thread "FLTK wont run (Visual Studios)" where you posted your new
videos. Great videos, BTW.

> What's the "right" thing we want here, so I can show the 'proper way' in the video:
>
> 1) Should new apps include both include dirs?

Yes, but only *if* they are *using* FLTK directly from the build
directory. This is not necessary if FLTK is installed anywhere else
after the build.

> 2) Should c:\fltk-1.4.x\FL\*.* files be (copied? moved?) into the build/FL?

No, that would not be useful. Otherwise changes to the FLTK headers
would be problematic (two versions would have to be maintained).

> 3) Should the abi file be moved into c:\fltk-1.4.x\FL\, and remove the build/FL directory?

No, see comments in fltk.general. TL;DR: a workaround would be to
install FLTK in another known directory where both FL folders would be
combined.

> I don't like 1 because that's just confusing and unprecidented.

See above.

> I don't like 2 because if copied, then there's two FL dirs (confusing), or if moved,
> then the FL directory isn't where it traditionally should be.

See above.

> Option 3 seems reasonable, as this I think is consistent with the unix builds (?),
> so that there's only one FL directory.

The Unix builds have exactly the same "issue" (in a neutral meaning):

(a) using autoconf/make places abi-version.h in the <source>/FL
directory which is bad but unavoidable because our autoconf build
doesn't support out-of-source builds.

(b) building with CMake creates <build>/FL/abi-version.h which is
correct (out of source). This results in two different FL/ folder
locations, but ...

(c) after installing a CMake generated build both FL/ directories get
installed to the same location.

> Ditto for the generated libs. Right now there's a c:\fltk-1.4.x\lib directory, but
> after a cmake/VS build all, the libs end up in "build/libs/Release/", which is confusing.

This is and has AFAICT always been the way Visual Studio works. It
creates different build directories for different build types (Debug vs.
Release). This way these multi-type build systems can also execute
different build types in a kinda parallel way.

> I think cmake is trying to allow us to have multiple builds using the same fltk directory,
> so that apps could link against different build dirs in the same fltk directory.

Yep. Or, more precise, link against many different build dirs anywhere
in the file system. It's not restricted to "build dirs in the (same)
fltk (root) directory".

> But doesn't that just make everything more complicated for the users that don't need
> such complexity? In the past, if people wanted multiple builds of FLTK, they'd make
> separate copies of the entire FLTK directory, and build each on its own, so there's
> no chance of overlap.

True, certainly, but with the cost that updates of the source tree would
need to be done multiple times as well.

BTW, if you're using Git having multiple source trees is really easy by
using `git worktree`.

> Is putting the resulting .H/.libs/test programs in separate build directories
> really a good idea, as compared the simpler "traditional" alternative?

In my opinion there's not much difference.

As I wrote above, VS always had this "multiple folders for different
build types" approach.

The other point, having two FL/ directories in the *build* and the
*source* tree can easily be mitigated by installing the build to another
directory. This is what I would recommend if not using CMake to build
one's own project(s).

If you're using CMake to build your own project, then there's no problem
at all and this entire discussion is moot.

So, after thinking about it, the Right Thing would IMHO be to recommend
to install the FLTK build to a known (good) location after the build.
This would avoid all these issues. The user must then select which build
they want to install (to which folder), can have multiple installs in
parallel, and build their own projects against different FLTK versions
and builds.

Using FLTK directly from the build directory would be the exception and
not the rule, but of course supported and likely often used by (FLTK)
developers.