Buiding FLTK on VS2017

[Osman Zakir]

I have Visual Studio Community 2017 on an Acer notebook with Windows 10 installed.  I've been having trouble building FLTK 1.3.4-1 from source.  I've attached the compiler output from my latest build attempt.  Please look at it and let me know what could be wrong.  Thanks in advance.

[Greg Ercolano]

On 03/23/17 15:23, Osman Zakir wrote:
> I have Visual Studio Community 2017 on an Acer notebook with Windows 10 installed. I've been having trouble building FLTK 1.3.4-1 from source. I've attached the compiler output from my latest build attempt. Please look at it and let me know what could be wrong. Thanks in advance.

Hmm, that's a strange path to FLTK's .H files:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\include\FL/Fl.H

I'm guessing you might have an old version of FLTK's include files installed
in the MSVC include directory, and they're causing problems building the newer
version of FLTK.


That would explain the numerous errors.

Short answer, rename the above FL directory tree (that's inside the MSVC directory)
to something else; rename it from FL to FL_OLD or some such, so that the compiler
doesn't pick it up while building 1.3.4-1.

Then try rebuilding FLTK.

You /may/ need to re-extract a fresh version of FLTK, since your last build
might have constructed bad IDE build files based on the old .H files.

[Osman Zakir]

It doesn't seem like I have two "FL" directories in my "include" directory.  There's just the one.  I deleted it just now to try to start fresh, though.  But I think even downloading FLTK again might not help.  I'll try either way.

I need FLTK for Mr. Stroustrup's intro C++ book, Programming: Principles and Practice Using C++ Second Edition.  Its Chapters 12-16 are on GUI programming, and it uses FLTK indirectly for the first bit and then apparently directly later.  I was able to successfully build FLTK earlier and used it for 3 exercises from Chapter 12, but then I don't know what I did wrong that made me continue to get linker errors whenever I tried to build the next exercise project I need to do.  I tried to reinstall FLTK but now that's also giving me problems.  I'll show you the header and .cpp files for GUI interface library for the book, too, if you want to see it.

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Greg Ercolano]

On 03/24/17 06:31, Osman Zakir wrote:
> It doesn't seem like I have two "FL" directories in my "include" directory.

IMHO shouldn't be *any* FL directory in VS's own include directory.
Only VS files should be there.

> There's just the one. I deleted it just now to try to start fresh, though.
> But I think even downloading FLTK again might not help. I'll try either way.

You don't have to re-download, just reinstall tar file so that
you resort to the original IDE files.

And if there's any step you're following that recommends putting
any files into VS's own include directory, I'd say stop there and
let us know what references doing that.

FLTK shouldn't need its include files to be installed anywhere else;
it should be completely built (and other apps built against it) while
all its files reside within the directory you extracted FLTK, e.g.
C:\fltk-1.3.4-1\ or something like that. It doesn't have to be in C:\,
it can be on your desktop even, or in your HOMEPATH directory.

> I need FLTK for Mr. Stroustrup's intro C++ book, /Programming:
> Principles and Practice Using C++ Second Edition/. Its Chapters 12-16

> are on GUI programming, and it uses FLTK indirectly for the first bit
> and then apparently directly later.

Yep, that all sounds fine.

> I was able to successfully build FLTK earlier and used it for 3 exercises
> from Chapter 12, but then I don't know what I did wrong that made me continue
> to get linker errors whenever I tried to build the next exercise project
> I need to do.

Perhaps it's too late, but if you posted your errors
and showed your linker lines and where FLTK was built,
that'd help.

What I'm curious about is how the FL directory ended up
/inside/ the visual studio distribution's directory.

Do you know how they got there?

Definitely don't do that. Better to modify your app build
instructions to append to the include path the location of
the top level FLTK directory you extracted the tar file to,
e.g.
C:\fltk-1.3.4-1

..which will allow VS to resolve things like "#include <FL/Fl.H>"

Similar for the lib directory, so that the linker can find the
.lib/.dll files, though you'd need to specify a deeper path,
like:

C:\fltk-1.3.4-1\lib

..to find the .lib files. I forget the path for .dll's.

> I tried to reinstall FLTK but now that's also giving me problems.

I still think the FL directory in the VS directory is causing
the problem, perhaps leftover from a previous install of FLTK
that somehow put a copy of the FL directory inside VS's own
directory.

> I'll show you the header and .cpp files for GUI interface library for the book, too, if you want to see it.

Not necessary for this situation, since you're getting errors
just building FLTK.

I think the FLTK build is failing because of an FL directory
copy in VS's own include directory that's eclipsing the compiler
from seeing the FL directory of fltk's own FL directory, and the
incompatibility between the older and newer FL files are causing the errors.

You have to understand that there should be no FL directory inside
of VS's own directory, e.g. what the errors were complaining about:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\include\FL/Fl.H

The FL files should not be located there.
No 3rd party software's include files should be put there IMHO.

[Greg Ercolano]

On 03/24/17 09:50, Greg Ercolano wrote:
> On 03/24/17 06:31, Osman Zakir wrote:
>> It doesn't seem like I have two "FL" directories in my "include" directory.
>
> IMHO shouldn't be *any* FL directory in VS's own include directory.
> Only VS files should be there.

And just to clarify, if I said two FL directories, I meant that one
that was in the VS directory:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\include\FL/Fl.H

..and the one that would be in your FLTK distribution directory, e.g.

C:\fltk-1.3.4-1\FL

When /both/ exist, VS would choose the one in the VS directory /first/
I think, which if it was an older FLTK version, would cause trouble
building different (e.g. newer) versions of FLTK.

[Osman Zakir]

How do I tell VS to make Multi-threaded DLLs? 

And in Appendix D of PPP2, Stroustrup says to put the FL folder in your native include directory after building FLTK.  So it should be after you've built it, but should I not do that after all?

For some reason, the linker's input options are set to files like fltk.lib, fltkd.lib, and etc., files that don't exist yet.  I don't get how that happened.  And it also can't find important files like stdio.h and stdlib.h.  What folders should I put the path to into Additional Include Directories so that it can find those headers?

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Osman Zakir]

I succeeded in building FLTK, finally.  It's after I ran System Restore.  I didn't take out the mentions of fltk.lib and fltkd.lib and etc. from Additional Dependencies in Linker Input options, but I did put the include path for the MSVS include folders (the normal one and the ucrt folder where I found stdio.h). 

I'll try building the projects I want to build with it now.  If I get errors, I'll come back here and ask about them. 

One thing, though.  How should I build x64 library files, and where should I put them (I don't want to replace the x86 ones with them, since I might need those as well). My laptop has a x64 processer, so I mainly want to build for x64 platforms, but preferably it should be "All Configurations" and "All Platforms" I think, if possible.  But the last time I tried to do that while building FLTK, I got errors.

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Albrecht Schlosser]

On 25.03.2017 12:10 Osman Zakir wrote:
> How do I tell VS to make Multi-threaded DLLs?

I don't know, this question is not related to FLTK. Sorry.

> And in Appendix D of PPP2, Stroustrup says to put the FL folder in your
> native include directory after building FLTK. So it should be after
> you've built it, but should I not do that after all?

This question is hard to answer. Let's say you want to do the exercises
described in the book. Before you can start you need to build FLTK.

Okay, let's assume you did. Before you can start the first exercise, you
need to create your test project (IDE solution) and refer it to the FLTK
include files and libs.

One way is to put the FLTK headers and libs in a path the VS compiler
and linker search anyway. In this case you wouldn't add anything to your
project settings but copy/move the FLTK headers and libs to some place
inside the VS directory tree. According to your description that's what
Bjarne Stroustrup recommends to do in his book.

My guess: you did this already some time ago. Now the (old) FLTK headers
and libs reside in the VS directory tree where the compiler finds them.
If this guess is correct, then any new FLTK version can fail to build
because the compiler finds the old (incompatible) headers in the VS
search tree. In this case you would have to remove the old FLTK lib (and
headers) from the VS directories *before* you can build another (maybe
newer) version of FLTK.

That scenario and its issues is one reason why we (the FLTK team)
usually recommend not to install the FLTK libs inside the VS directory
tree. Note: unfortunately there _is_ such advice in one of our README
files, but this is no longer recommended.

The second way to let the compiler and linker find the FLTK libs is to
add the appropriate search paths to the FLTK header files and .lib files
in the VS setup of "additional include files" and "additional library
paths" or similar. Since your project can point to different
installation directories you may have on your disk this is the
recommended way.

> For some reason, the linker's input options are set to files like
> fltk.lib, fltkd.lib, and etc., files that don't exist yet.

The linker's input options of which project? Your book exercises? Can
this be from your earlier attempts?

> I don't get how that happened. And it also can't
> find important files like stdio.h and stdlib.h.

That's strange. I can't help with this. Maybe your VS installation is
broken?

> What folders should I put the path to into Additional
> Include Directories so that it can find those headers?

If you built FLTK with the bundled IDE solution, then this should be:

X:\path\to\fltk\ide\VisualC2010

You should also add to "Linker/Additional Library Directories":

X:\path\to\fltk\ide\VisualC2010\lib

Replace X:\path\to\fltk with the path where you unpacked the FLTK sources.

Note: FLTK itself (i.e. the bundled IDE solution in FLTK's
ide/VisualC2010 folder) should build without errors. If you get errors
(you should ignore all warnings) then you must remove old FLTK headers
and libs from the VS installation directiories. The additional library
and header paths above should only be added to your (book exercise)
project(s).

[Ian MacArthur]

On Friday, 24 March 2017 16:50:43 UTC, Greg Ercolano wrote:

        What I'm curious about is how the FL directory ended up
        /inside/ the visual studio distribution's directory.

        Do you know how they got there?

In case it's not already been said, ISTR that Dr. S's book suggests doing that, so I assume the OP was following that advice.

Whether you or I would consider that Good Advice is another matter...

 

        Definitely don't do that. Better to modify your app build
        instructions to append to the include path the location of
        the top level FLTK directory you extracted the tar file to,
        e.g.
                C:\fltk-1.3.4-1

 

Yes, I imagine Dr. S was attempting to avoid having the explain how to set up the include and lib search paths on the various different IDE's that the students might have.

I don't think I'd go that way myself, but... I guess it was a long while ago now, and we haven't seen a lot of fall-out from it before now, so perhaps it is an OK strategy in a lot of cases after all?

[Greg Ercolano]

On 03/26/17 13:39, Ian MacArthur wrote:
> Definitely don't do that. Better to modify your app build
> instructions to append to the include path the location of
> the top level FLTK directory you extracted the tar file to,
> e.g.
> C:\fltk-1.3.4-1
>
> Yes, I imagine Dr. S was attempting to avoid having the explain
> how to set up the include and lib search paths on the various
> different IDE's that the students might have.

Argh, but it sets such a bad example to modify the compiler
environment. Not to mention the weird crashing problems
when you install new versions of the lib, but forget to
update the compiler dirs.

Then it's up to us to try to figure out why simple hello world
apps crash unexpectedly or give strange compiler errors.

But I guess it doesn't help that the VS IDE keeps moving
the dialogs around for setting the include/lib paths.

> we haven't seen a lot of fall-out from it before now

But I think we have. Every so often people have hard to debug
scary crashing issues that turn out to be include files from
mismatched fltk versions.

The IDEs definitely make this hard, though. At the compiler line
it's certainly simple enough to just add /I\path for MS compilers,
and -I/path for everything else. That hasn't changed since the 80's
for all platforms/compilers. But throw a gui on the compiler, and all
bets are off as to standard techniques for setting these things :(

[Greg Ercolano]

>> we haven't seen a lot of fall-out from it before now
>
> But I think we have. Every so often people have hard to debug
> scary crashing issues that turn out to be include files from
> mismatched fltk versions.

Hmm, I seem to recall once discussing a way to detect this situation
to avoid the ugly crashes.

Would it be possible to have e.g. Fl.cxx do some macro checks
to make sure the version#s in the .H files match what it expects?
Maybe something as simple as:

#if FL_MAJOR_VERSION != 1 || FL_MINOR_VERSION != 3 || FL_PATCH_VERSION != "4"
# error FLTK include files don't match version being built
#endif

with perhaps a comment citation above it:

// Detect if FLTK being built against incompatible include files
// e.g. someone has an old FL directory installed in /usr/include
//

[imm]

On 26 March 2017 at 22:18, Greg Ercolano wrote:

        The IDEs definitely make this hard, though. At the compiler line
        it's certainly simple enough to just add /I\path for MS compilers,
        and -I/path for everything else. That hasn't changed since the 80's
        for all platforms/compilers. But throw a gui on the compiler, and all
        bets are off as to standard techniques for setting these things :(

​FWIW, ​recent iterations of "cl" seem to be perfectly happy with "-I" for include paths; indeed it seems to accept "-" as a substitute for its usual use of "/" for options generally.

I know this because I cobbled together a wrapper for "cl" that (almost) allows me to drop it in, in place of gcc in a standard Makefile, with auto dependency generation etc., and it pretty much works. (Well, for that one project, anyway. Not sure how general a solution it is...) Once you get past it's quirks, its a pretty decent compiler these days.

Totally agree about IDE's just confusing matters though!

[Osman Zakir]

I mentioned before that I already managed to build FLTK.  I just need to know how to build correct x64 platform-targeting libs for it so I can compile and link with x64 platform configuration, too.  Right now I can only do it with x86.

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Albrecht Schlosser]

On 26.03.2017 23:34 Greg Ercolano wrote:
>>> we haven't seen a lot of fall-out from it before now
>>
>> But I think we have. Every so often people have hard to debug
>> scary crashing issues that turn out to be include files from
>> mismatched fltk versions.
>
> Hmm, I seem to recall once discussing a way to detect this situation
> to avoid the ugly crashes.

Yes, we did, and created static int Fl::abi_check().
<http://www.fltk.org/doc-1.3/classFl.html#aeec1fc58b2ded93866e75fc0f317b284>

>
> Would it be possible to have e.g. Fl.cxx do some macro checks
> to make sure the version#s in the .H files match what it expects?
> Maybe something as simple as:
>
> #if FL_MAJOR_VERSION != 1 || FL_MINOR_VERSION != 3 || FL_PATCH_VERSION != "4"
> # error FLTK include files don't match version being built
> #endif
>
> with perhaps a comment citation above it:
>
> // Detect if FLTK being built against incompatible include files
> // e.g. someone has an old FL directory installed in /usr/include
> //

FL/Fl.H has:

static inline int abi_check(const int val = FL_ABI_VERSION) {
return val == abi_version();
}

So this _can_ be used to check the ABI version and emit a warning or
error message. We don't use it in the library though.

We might call it internally, maybe in Fl::run() and fire up an error
dialog message or write something to stderr, but some of the errors with
incompatible versions appear at compile or link time so we don't reach
Fl::run() at all.

OTOH: using Fl::abi_check() internally and issuing a warning/error
message would help to avoid some runtime crashes or other strange
effects (ABI incompatibilities).

Thoughts?

[Albrecht Schlosser]

On 27.03.2017 01:31 Osman Zakir wrote:
> I mentioned before that I already managed to build FLTK. I just need to
> know how to build correct x64 platform-targeting libs for it so I can
> compile and link with x64 platform configuration, too. Right now I can
> only do it with x86.

I have VS 2015 Community available and I know that the IDE has a
function to convert the entire project from x86 to x64 platform and vice
versa. Click on the target platform selection box right of the
Debug/Release selection and use "Configuration Manager..." to select the
'x64' platform. However, I don't know if this works. I once tried to
convert the bundled ide/VisualC2010 project with VS 2010 Express and it
failed. I gave up after some unsuccessful tries.

The other way to get a x64 build environment (VS IDE solution) is to use
CMake to generate one yourself. This works flawlessly with FLTK 1.3.4 as
well as FLTK 1.4.x (development branch). Note: this will be necessary
once you switch to FLTK 1.4 anyway.

There are instructions in README.MSWindows.txt and README.CMake.txt how
to do this. In a nutshell:

- download CMake (Windows binary/installer)
- start CMake (cmake-gui)
- select a clean build directory (will be created by CMake)
- select the FLTK source directory (root dir)
- click on 'Configure'
- select "Visual Studio 14 2015 Win64" or other "...Win64" type
- click on 'Finish'
- CMake does its checks and reports in the log window
- click on 'Generate'
- CMake builds your IDE solution
- close the CMake window

Now you should have several files including FLTK.sln in your build
directory. Open FLTK.sln with your IDE (or click on it in the Windows
Explorer), build solution and enjoy...

[Osman Zakir]

What do if I get errors in CMake?  I've tried it a few times, but it gives errors about CMakeLists being wrong or whatnot (most recent try). 

VS2017 comes with CMake.  I just don't know how to use it from within the IDE. 

But when you say I'll need to use CMake with FLTK 1.4.x, do you mean to say that VS2017 alone (without using the built-in CMake) won't work?

Anyway, I tried doing CMake before submitting this message and it gave me 88 VS project files.  When I used VS to try to build FLTK.sln, with the Debug configuration, it skipped 2 projects but successfully built the other 86.  I generated x64 projects with CMake for this. 

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Osman Zakir]

I tried to build a x64 project using FLTK, but the linker can't find X11/Xlib.h.  I saw a post on Stack Overflow that said that Xllibs don't work on Visual Studio.  So that's why the x64 platform target builds of FLTK user projects don't work in Visual Studio. 

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Albrecht Schlosser]

On 27.03.2017 14:57 Osman Zakir wrote:
> What do if I get errors in CMake? I've tried it a few times, but it
> gives errors about CMakeLists being wrong or whatnot (most recent try).

Please post real error messages (cut and paste text) so we can help you
better.

> VS2017 comes with CMake. I just don't know how to use it from within
> the IDE.

Neither do I. I didn't install VS 2017 yet.

> But when you say I'll need to use CMake with FLTK 1.4.x, do you mean to
> say that VS2017 alone (without using the built-in CMake) won't work?

I'm not keen on Microsoft's CMake (what did they change?) - I'd rather
install native CMake and run it to generate the IDE project files in the
first place. But I'll try VS 2017 when time permits...

> Anyway, I tried doing CMake before submitting this message and it gave
> me 88 VS project files. When I used VS to try to build FLTK.sln, with
> the Debug configuration, it skipped 2 projects but successfully built
> the other 86. I generated x64 projects with CMake for this.

Great!

The two skipped projects are okay. I believe these are CMake
(re)generation projects that must be "built" only if the CMake
configuration files (CMakeLists.txt) were changed. The other 86 projects
are the libraries, fluid, and all the test and demo programs.

[Albrecht Schlosser]

On 27.03.2017 15:13 Osman Zakir wrote:
> I tried to build a x64 project using FLTK, but the linker can't find
> X11/Xlib.h. I saw a post on Stack Overflow that said that Xllibs don't
> work on Visual Studio.

That's true so far. X11 is used on Unix/Linux and MacOS and some other
OS's, but usually not on Windows (Cygwin on Windows is a well-known
exception).

> So that's why the x64 platform target builds of
> FLTK user projects don't work in Visual Studio.

The reason this happens is because you didn't define WIN32 as
compiler/preprocessor macro (its value doesn't matter, just define it).
Please see README.MSWindows.txt:

"add "WIN32" to the C++ Preprocessor Definitions (Configuration
Properties > C/C++ > Preprocessor > Preprocessor Definitions)."

This must be done in each user project so FLTK "knows" it's compiled
under Windows. This is a necessary convention in current FLTK and is
documented.

If you add the WIN32 definition your project should build, no matter if
you use x86 (32-bit) or x64 (64-bit) mode.

[Osman Zakir]

Thanks, Albrecht.  I'll try that definition. 

As for CMake, I think it might be more accurate to say that VS 2017 supports CMake builds better.  They also have a compiler flag for CMake builds now.

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Osman Zakir]

On Debug configuration with x64, I had a whole bunch of linker warnings about PDB info files not being found, and it saying that it's linking with the project as if there's no Debug info.  Release configuration seems to be better.

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Albrecht Schlosser]

On 28.03.2017 11:36 Osman Zakir wrote:
> Thanks, Albrecht. I'll try that definition.
>
> As for CMake, I think it might be more accurate to say that VS 2017
> supports CMake builds better. They also have a compiler flag for CMake
> builds now.

Thanks, I'll check that when time permits and report back.

PS: please don't top-post and click 'reply' to the message you're
actually replying to, then trim the cited text. This makes it much
easier to follow the discussion. Thanks.

[Albrecht Schlosser]

On 28.03.2017 12:12 Osman Zakir wrote:
> On Debug configuration with x64, I had a whole bunch of linker warnings
> about PDB info files not being found, and it saying that it's linking
> with the project as if there's no Debug info.

Please post real error messages, not descriptions. You can cut and paste
text from the VS log window.

> Release configuration seems to be better.

I don't think so, it depends on what you need. If you want to debug or
view a stack trace when a program crashes you need debug info, i.e. the
Debug configuration. If you want to produce a smaller exe file for
deployment you may want to use the Release configuration.

That said, I tried both Release and Debug configurations with VS2015 and
did not get such warnings, even if I switched configurations without
cleaning the solution. Maybe something is different with VS2017? Anyway,
please use 'Build/Clean Solution' before you switch configurations. Is
this any better? If this doesn't help, what happens if you create a
fresh build directory and run 'Build/Build Solution' in Release
configuration as the first build step?

Last but not least: how did you create your IDE files:

(1) with downloaded CMake (which version?)
(2) with VS's built-in CMake (which version?)

[Albrecht Schlosser]

On 29.03.2017 09:58 Albrecht Schlosser wrote:
>
> ... If this doesn't help, what happens if you create a

> fresh build directory and run 'Build/Build Solution' in Release
> configuration as the first build step?

Sorry, this should read: '... in _Debug_ configuration ...'

[Osman Zakir]

For x64, both Debug and Release, I used CMake.  Latest stable version available if I'm not wrong. 

As for the Build output on x64 Debug configuration, here's a link to a file on my OneDrive where I've put it: https://1drv.ms/t/s!As6LkLqTe7Ps8AQkQAosSvAAN82a

On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:

[Greg Ercolano]

> On Friday, March 24, 2017 at 3:30:19 AM UTC+5, Osman Zakir wrote:
>
> I have Visual Studio Community 2017 on an Acer notebook with Windows 10 installed.
> I've been having trouble building FLTK 1.3.4-1 from source. I've attached the
> compiler output from my latest build attempt. Please look at it and let me know
> what could be wrong. Thanks in advance.

On 05/01/17 07:02, Osman Zakir wrote:
> Sorry, that's the wrong file. I'll try attaching the right one now.
> https://1drv.ms/t/s!As6LkLqTe7Ps8AQkQAosSvAAN82a

Basically, a lot these errors (in case the above link goes stale):

snip ___________________________________________________________________________________ snip
1>------ Build started: Project: color-chart, Configuration: Debug x64 ------
1>fltkd.lib(Fl.obj) : warning LNK4099: PDB 'fltk.pdb' was not found with 'fltkd.lib(Fl.obj)' or at 'C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\fltk.pdb'; linking object as if no debug info
1>fltkd.lib(Fl_Bitmap.obj) : warning LNK4099: PDB 'fltk.pdb' was not found with 'fltkd.lib(Fl_Bitmap.obj)' or at 'C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\fltk.pdb'; linking object as if no debug info
1>fltkd.lib(Fl_Box.obj) : warning LNK4099: PDB 'fltk.pdb' was not found with 'fltkd.lib(Fl_Box.obj)' or at 'C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\fltk.pdb'; linking object as if no debug info
1>fltkd.lib(Fl_Button.obj) : warning LNK4099: PDB 'fltk.pdb' was not found with 'fltkd.lib(Fl_Button.obj)' or at 'C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\fltk.pdb'; linking object as if no debug info
..etc for several pages..
1>Done building project "color-chart.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
snip ___________________________________________________________________________________ snip


Note that it didn't fail, it just printed a warning related to being
unable to find the debugging file 'fltk.pdb'.

I googled for the warning and came up with this:
https://msdn.microsoft.com/en-us/library/5ske5b71.aspx

"""
Linker Tools Warning LNK4204
'filename' is missing debugging information for referencing module; linking object as if no debug info

The .pdb file has an erroneous signature. The linker will continue to link the object without
debug information. You may want to recompile the object file using the /Zi option.

LNK4204 can occur if some of the objects in the library refer to a file that
no longer exists. This could happen when rebuilding the solution, for example;
an object file might be deleted and not rebuilt because of a compilation error.
In this case, either compile with /Z7, or /Fd, to update the objects to refer
to a single file per-library (that is not the default .pdb file name).
For more information, see /Fd (Program Database File Name). Ensure that
the .pdb is saved with the library every time it is updated in the
source control system.
"""

I can't see from your build output what compile flags were used to build
FLTK, but you might want to check if it jibes with the above (e.g. missing /Zi?)
by doing a clean rebuild of FLTK and look for those flags it describes.

Are you trying to debug fltk? If not, then try building as a normal release
instead of with fltk debug enabled; it'll make smaller/more efficient binaries.
See the README.CMake.txt build options. To build a normal release, you'd want
I think:

cmake -D CMAKE_BUILD_TYPE=Release

[Osman Zakir]

I'm aware that it didn't fail.  I'm specifically asking about those warnings that say that it's linking as if there's no Debug info.  And what I tried to build here is a user program, not FLTK itself.  I don't really know how to set compilation flags in CMake, so I'll have to try building FLTK for x64 in VS itself.  You'll have to give me tips on what compiler flags to set, though.  I think one is /Zi or /Zd? 

These are the compiler flags I used to build this user program, by the way:

/

GS- /W3 /Zc:wchar_t /I"C:\Program Files (x86)\fltk-1.3.4-1" /ZI /Gm /Od /Fd"x64\Debug\vc141.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /std:c++14 /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Fp"x64\Debug\color-chart.pch" /diagnostics:classic

[Greg Ercolano]

On 05/01/17 12:02, Osman Zakir wrote:
> I'm aware that it didn't fail. I'm specifically asking about those warnings
> that say that it's linking as if there's no Debug info. And what I tried
> to build here is a user program, not FLTK itself.

Let's see your linker flags.

I'd suggest comparing those flags to the flags FLTK built one of
its test programs with (e.g. test\hello.cxx), and look for differences.

You can find out FLTK's compile/link flags by rebuilding just one
of the FLTK test programs (e.g. "hello") within the FLTK project
your last cmake created for you, and then look at the build history
file that includes all the compile/link flags.

Check especially for any link flags or file specifications
that might disagree with the ones you're using to build your app.

> These are the compiler flags I used to build this user program, by the way:

> GS- /W3 /Zc:wchar_t /I"C:\Program Files (x86)\fltk-1.3.4-1" /ZI /Gm
> /Od /Fd"x64\Debug\vc141.pdb" /Zc:inline /fp:precise /D "WIN32"
> /D "_DEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE"
> /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd
> /std:c++14 /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\"
> /Fp"x64\Debug\color-chart.pch" /diagnostics:classic

Those appear to be compiler flags, but I think perhaps more relevant
would be your link flags, as those were linker warnings.

[Osman Zakir]

Linker flags:

/OUT:"C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\color-chart.exe" /MANIFEST /NXCOMPAT /PDB:"C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\color-chart.pdb" /DYNAMICBASE "fltkd.lib" "fltk_formsd.lib" "fltk_gld.lib" "fltk_imagesd.lib" "fltk_jpegd.lib" "fltk_pngd.lib" "fltk_zd.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FASTLINK /MACHINE:X64 /NODEFAULTLIB:"libcd.lib" /INCREMENTAL /PGD:"C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\color-chart.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\color-chart.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files (x86)\fltk-1.3.4-1\lib\x64" /TLBID:1

And this is the main error message I get when I try build FLTK x64 Release in VS2017:

1>.\adjuster_release\adjuster.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 

Does this mean that the copy of FLTK I'm using is x86 which is conflicting with the target machine type x64?

[Greg Ercolano]

On 05/01/17 13:05, Osman Zakir wrote:
> Linker flags:
>
> /OUT:"C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\color-chart.exe"
> /MANIFEST /NXCOMPAT /PDB:"C:\Users\Osman\programming\visual studio 2017\Projects\programming_principles_practice_using_c++\color-chart\x64\Debug\color-chart.pdb"
> /DYNAMICBASE "fltkd.lib"

OK, that last line "fltkd.lib" would seem to indicate FLTK was compiled in debug mode,
as all the FLTK oriented lib references end in 'd' (fltk*d*.lib).

So you're definitely linking against a debug build of FLTK here.

How do these linker flags compare with the ones FLTK used to build one of
its test programs?

> And this is the main error message I get when I try build FLTK x64 Release in VS2017:
> 1>.\adjuster_release\adjuster.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
> Does this mean that the copy of FLTK I'm using is x86 which is conflicting with the target machine type x64?

That means adjuster.obj was built x86, but the linker is being told to link it
as an x64 target.

This could happen if you'd previously done a 32bit build of FLTK, changed
to a 64bit build, and didn't do a clean rebuild of FLTK when building x64.

Be sure to do a "clean" rebuild of FLTK; make sure it deletes any old .obj
files before rebuilding, so it doesn't try to reuse old objs.

If you still get that error, then I'd again compare the compiler + linker
flags to look for discrepancies, in case the compile stage is missing 64bit
flags.

I don't have a VS2017/cmake build environment here, so I'm kinda operating
blind. It doesn't help I'm not too familiar with the cmake build environment
myself; others here might be able to help more.. but they might be too busy
to reply.

[Osman Zakir]

I cleaned it and tried to build it again, but I still get the same problem.  And if it's doing a Debug configuration, then I don't know what's wrong because I have "Release" selected here. 

Here's my build output:

1>------ Build started: Project: fltkzlib, Configuration: Release Win32 ------
2>------ Build started: Project: fltkjpeg, Configuration: Release Win32 ------
2>jcapimin.c
2>jcapistd.c
2>jccoefct.c
2>jccolor.c
2>jcdctmgr.c
2>jchuff.c
2>jcinit.c
2>jcmainct.c
1>adler32.c
1>compress.c
1>crc32.c
1>deflate.c
2>jcmarker.c
1>gzclose.c
1>gzlib.c
1>gzread.c
2>jcmaster.c
1>gzwrite.c
1>infback.c
2>jcomapi.c
2>jcparam.c
1>inffast.c
2>jaricom.c
1>inflate.c
2>jcarith.c
1>inftrees.c
2>jdarith.c
1>trees.c
2>jcprepct.c
1>uncompr.c
1>zutil.c
2>jcsample.c
2>jctrans.c
1>Generating Code...
2>jdapimin.c
2>jdapistd.c
2>Generating Code...
2>Compiling...
2>jdatadst.c
2>jdatasrc.c
2>jdcoefct.c
1>zlib.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkzlib.lib
3>------ Build started: Project: fltkpng, Configuration: Release Win32 ------
2>jdcolor.c
2>jddctmgr.c
3>png.c
2>jdhuff.c
2>jdinput.c
2>jdmainct.c
2>jdmarker.c
2>jdmaster.c
2>jdmerge.c
2>jdpostct.c
2>jdsample.c
2>jdtrans.c
3>pngerror.c
2>jerror.c
2>jfdctflt.c
2>jfdctfst.c
3>pngget.c
2>jfdctint.c
2>jidctflt.c
3>pngmem.c
2>jidctfst.c
2>Generating Code...
3>pngpread.c
2>Compiling...
2>jidctint.c
2>jmemmgr.c
3>pngread.c
2>jmemnobs.c
2>jquant1.c
2>jquant2.c
3>pngrio.c
2>jutils.c
2>Generating Code...
3>pngrtran.c
3>pngrutil.c
2>jpeg.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkjpeg.lib
3>pngset.c
3>pngtrans.c
3>pngwio.c
3>pngwrite.c
3>pngwtran.c
3>pngwutil.c
3>Generating Code...
3>libpng.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkpng.lib
4>------ Build started: Project: fltk, Configuration: Release Win32 ------
4>        1 file(s) copied.
4>case.c
4>fl_call_main.c
4>fl_utf.c
4>flstring.c
4>is_right2left.c
4>is_spacing.c
4>numericsort.c
4>scandir.c
4>vsnprintf.c
4>Generating Code...
4>filename_absolute.cxx
4>filename_expand.cxx
4>filename_ext.cxx
4>filename_isdir.cxx
4>filename_list.cxx
4>filename_match.cxx
4>filename_setext.cxx
4>Fl.cxx
4>Fl_abort.cxx
4>Fl_add_idle.cxx
4>Fl_Adjuster.cxx
4>fl_arc.cxx
4>fl_arci.cxx
4>Fl_arg.cxx
4>fl_ask.cxx
4>Fl_Bitmap.cxx
4>Fl_Box.cxx
4>fl_boxtype.cxx
4>Fl_Browser.cxx
4>Fl_Browser_.cxx
4>Generating Code...
4>Compiling...
4>Fl_Browser_load.cxx
4>Fl_Button.cxx
4>Fl_Cairo.cxx
4>Fl_Chart.cxx
4>Fl_Check_Browser.cxx
4>Fl_Check_Button.cxx
4>Fl_Choice.cxx
4>Fl_Clock.cxx
4>fl_color.cxx
4>Fl_Color_Chooser.cxx
4>Fl_compose.cxx
4>Fl_Copy_Surface.cxx
4>Fl_Counter.cxx
4>fl_cursor.cxx
4>fl_curve.cxx
4>Fl_Device.cxx
4>Fl_Dial.cxx
4>fl_diamond_box.cxx
4>Fl_display.cxx
4>fl_dnd.cxx
4>Generating Code...
4>Compiling...
4>Fl_Double_Window.cxx
4>fl_draw.cxx
4>fl_draw_image.cxx
4>fl_draw_pixmap.cxx
4>fl_engraved_label.cxx
4>Fl_File_Browser.cxx
4>Fl_File_Chooser.cxx
4>Fl_File_Chooser2.cxx
4>fl_file_dir.cxx
4>Fl_File_Icon.cxx
4>Fl_File_Input.cxx
4>fl_font.cxx
4>Fl_get_key.cxx
4>Fl_get_system_colors.cxx
4>Fl_grab.cxx
4>Fl_Group.cxx
4>fl_gtk.cxx
4>fl_gleam.cxx
4>Fl_Help_View.cxx
4>Fl_Image.cxx
4>Generating Code...
4>Compiling...
4>Fl_Image_Surface.cxx
4>Fl_Input.cxx
4>Fl_Input_.cxx
4>fl_labeltype.cxx
4>Fl_Light_Button.cxx
4>fl_line_style.cxx
4>Fl_lock.cxx
4>Fl_Menu.cxx
4>Fl_Menu_.cxx
4>Fl_Menu_add.cxx
4>Fl_Menu_Bar.cxx
4>Fl_Menu_Button.cxx
4>Fl_Menu_global.cxx
4>Fl_Menu_Window.cxx
4>Fl_Multi_Label.cxx
4>Fl_Native_File_Chooser.cxx
4>fl_open_uri.cxx
4>fl_oval_box.cxx
4>fl_overlay.cxx
4>fl_overlay_visual.cxx
4>Generating Code...
4>Compiling...
4>Fl_Overlay_Window.cxx
4>Fl_own_colormap.cxx
4>Fl_Pack.cxx
4>Fl_Paged_Device.cxx
4>Fl_Pixmap.cxx
4>fl_plastic.cxx
4>Fl_Positioner.cxx
4>Fl_PostScript.cxx
4>Fl_Preferences.cxx
4>Fl_Printer.cxx
4>Fl_Progress.cxx
4>fl_read_image.cxx
4>fl_rect.cxx
4>Fl_Repeat_Button.cxx
4>Fl_Return_Button.cxx
4>Fl_Roller.cxx
4>fl_round_box.cxx
4>Fl_Round_Button.cxx
4>fl_rounded_box.cxx
4>Fl_Scroll.cxx
4>Generating Code...
4>Compiling...
4>fl_scroll_area.cxx
4>Fl_Scrollbar.cxx
4>fl_set_font.cxx
4>fl_set_fonts.cxx
4>fl_shadow_box.cxx
4>Fl_Shared_Image.cxx
4>fl_shortcut.cxx
4>fl_show_colormap.cxx
4>Fl_Single_Window.cxx
4>Fl_Slider.cxx
4>fl_symbols.cxx
4>Fl_Table.cxx
4>Fl_Table_Row.cxx
4>Fl_Tabs.cxx
4>Fl_Text_Buffer.cxx
4>Fl_Text_Display.cxx
4>Fl_Text_Editor.cxx
4>Fl_Tile.cxx
4>Fl_Tiled_Image.cxx
4>Fl_Tooltip.cxx
4>Generating Code...
4>Compiling...
4>Fl_Tree.cxx
4>Fl_Tree_Item.cxx
4>Fl_Tree_Item_Array.cxx
4>Fl_Tree_Prefs.cxx
4>fl_utf8.cxx
4>Fl_Valuator.cxx
4>Fl_Value_Input.cxx
4>Fl_Value_Output.cxx
4>Fl_Value_Slider.cxx
4>fl_vertex.cxx
4>Fl_visual.cxx
4>Fl_Widget.cxx
4>Fl_Window.cxx
4>Fl_Window_fullscreen.cxx
4>Fl_Window_hotspot.cxx
4>Fl_Window_iconize.cxx
4>Fl_Window_shape.cxx
4>Fl_Wizard.cxx
4>Fl_x.cxx
4>Fl_XBM_Image.cxx
4>Generating Code...
4>Compiling...
4>Fl_XPM_Image.cxx
4>ps_image.cxx
4>screen_xywh.cxx
4>Generating Code...
4>fltk.lib.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltk.lib
5>------ Build started: Project: fltkimages, Configuration: Release Win32 ------
6>------ Build started: Project: fltkforms, Configuration: Release Win32 ------
7>------ Build started: Project: fltkgl, Configuration: Release Win32 ------
8>------ Build started: Project: ask, Configuration: Release Win32 ------
6>forms_bitmap.cxx
6>forms_compatability.cxx
8>ask.cxx
6>forms_free.cxx
6>forms_fselect.cxx
6>forms_pixmap.cxx
8>.\ask_release\ask.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
8>Done building project "ask.vcxproj" -- FAILED.
9>------ Build started: Project: bitmap, Configuration: Release Win32 ------
6>forms_timer.cxx
9>bitmap.cxx
5>Fl_BMP_Image.cxx
5>Fl_File_Icon2.cxx
5>Fl_GIF_Image.cxx
6>Generating Code...
5>Fl_Help_Dialog.cxx
5>fl_images_core.cxx
5>Fl_JPEG_Image.cxx
5>Fl_PNG_Image.cxx
5>Fl_PNM_Image.cxx
5>Generating Code...
9>.\bitmap_release\bitmap.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
9>Done building project "bitmap.vcxproj" -- FAILED.
10>------ Build started: Project: boxtype, Configuration: Release Win32 ------
6>fltkforms.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkforms.lib
5>fltkimages.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkimages.lib
11>------ Build started: Project: browser, Configuration: Release Win32 ------
12>------ Build started: Project: pixmap_browser, Configuration: Release Win32 ------
10>boxtype.cxx
7>Fl_Gl_Choice.cxx
7>Fl_Gl_Device_Plugin.cxx
7>Fl_Gl_Overlay.cxx
7>Fl_Gl_Window.cxx
7>freeglut_geometry.cxx
7>freeglut_stroke_mono_roman.cxx
7>freeglut_stroke_roman.cxx
11>browser.cxx
10>.\boxtype_release\boxtype.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
10>Done building project "boxtype.vcxproj" -- FAILED.
13>------ Build started: Project: button, Configuration: Release Win32 ------
11>.\browser_release\browser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
11>Done building project "browser.vcxproj" -- FAILED.
14>------ Build started: Project: buttons, Configuration: Release Win32 ------
12>pixmap_browser.cxx
12>.\pixmap_browser_release\pixmap_browser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
12>Done building project "pixmap_browser.vcxproj" -- FAILED.
15>------ Build started: Project: fltkdll, Configuration: Release Win32 ------
14>buttons.cxx
15>case.c
14>.\buttons_release\buttons.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>fl_utf.c
14>Done building project "buttons.vcxproj" -- FAILED.
16>------ Build started: Project: clock, Configuration: Release Win32 ------
15>is_right2left.c
15>is_spacing.c
15>Generating Code...
7>freeglut_teapot.cxx
7>gl_draw.cxx
7>gl_start.cxx
7>glut_compatability.cxx
13>button.cxx
15>filename_absolute.cxx
16>clock.cxx
13>.\button_release\button.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
13>Done building project "button.vcxproj" -- FAILED.
17>------ Build started: Project: colbrowser, Configuration: Release Win32 ------
16>.\clock_release\clock.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>filename_expand.cxx
16>Done building project "clock.vcxproj" -- FAILED.
18>------ Build started: Project: color_chooser, Configuration: Release Win32 ------
17>colbrowser.cxx
15>filename_ext.cxx
15>filename_isdir.cxx
15>filename_list.cxx
7>glut_font.cxx
7>Generating Code...
15>filename_match.cxx
18>color_chooser.cxx
17>.\colbrowser_release\colbrowser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
17>Done building project "colbrowser.vcxproj" -- FAILED.
19>------ Build started: Project: cursor, Configuration: Release Win32 ------
15>filename_setext.cxx
18>.\color_chooser_release\color_chooser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
18>Done building project "color_chooser.vcxproj" -- FAILED.
20>------ Build started: Project: curve, Configuration: Release Win32 ------
15>Fl.cxx
19>cursor.cxx
7>fltkgl.vcxproj -> C:\Program Files (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkgl.lib
21>------ Build started: Project: cube, Configuration: Release Win32 ------
19>.\cursor_release\cursor.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
19>Done building project "cursor.vcxproj" -- FAILED.
22>------ Build started: Project: doublebuffer, Configuration: Release Win32 ------
22>doublebuffer.cxx
20>curve.cxx
15>Fl_abort.cxx
20>.\curve_release\curve.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
20>Done building project "curve.vcxproj" -- FAILED.
23>------ Build started: Project: file_chooser, Configuration: Release Win32 ------
15>Fl_add_idle.cxx
15>Fl_Adjuster.cxx
21>cube.cxx
23>file_chooser.cxx
15>fl_arc.cxx
22>.\doublebuffer_release\doublebuffer.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
22>Done building project "doublebuffer.vcxproj" -- FAILED.
24>------ Build started: Project: fonts, Configuration: Release Win32 ------
15>fl_arci.cxx
23>.\file_chooser_release\file_chooser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
23>Done building project "file_chooser.vcxproj" -- FAILED.
25>------ Build started: Project: forms, Configuration: Release Win32 ------
21>.\cube_release\cube.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
21>Done building project "cube.vcxproj" -- FAILED.
26>------ Build started: Project: fractals, Configuration: Release Win32 ------
25>forms.cxx
15>Fl_arg.cxx
24>fonts.cxx
24>.\fonts_release\fonts.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
24>Done building project "fonts.vcxproj" -- FAILED.
27>------ Build started: Project: fullscreen, Configuration: Release Win32 ------
15>fl_ask.cxx
27>fullscreen.cxx
25>.\forms_release\forms.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
25>Done building project "forms.vcxproj" -- FAILED.
28>------ Build started: Project: gl_overlay, Configuration: Release Win32 ------
15>Fl_Bitmap.cxx
29>------ Build started: Project: glpuzzle, Configuration: Release Win32 ------
27>.\fullscreen_release\fullscreen.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
27>Done building project "fullscreen.vcxproj" -- FAILED.
30>------ Build started: Project: hello, Configuration: Release Win32 ------
28>gl_overlay.cxx
29>glpuzzle.cxx
28>.\gl_overlay_release\gl_overlay.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>Fl_BMP_Image.cxx
28>Done building project "gl_overlay.vcxproj" -- FAILED.
31>------ Build started: Project: help, Configuration: Release Win32 ------
15>Fl_Box.cxx
31>help.cxx
15>fl_boxtype.cxx
29>..\..\test\glpuzzle.cxx(107): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
29>..\..\test\glpuzzle.cxx(187): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
29>..\..\test\glpuzzle.cxx(217): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
29>..\..\test\glpuzzle.cxx(334): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
29>..\..\test\glpuzzle.cxx(1333): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
29>..\..\test\glpuzzle.cxx(1337): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
30>hello.cxx
29>.\glpuzzle_release\glpuzzle.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
29>Done building project "glpuzzle.vcxproj" -- FAILED.
32>------ Build started: Project: iconize, Configuration: Release Win32 ------
30>.\hello_release\hello.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
30>Done building project "hello.vcxproj" -- FAILED.
33>------ Build started: Project: image, Configuration: Release Win32 ------
15>Fl_Browser.cxx
31>.\help_release\help.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
31>Done building project "help.vcxproj" -- FAILED.
34>------ Build started: Project: input, Configuration: Release Win32 ------
33>image.cxx
34>input.cxx
15>Generating Code...
32>iconize.cxx
15>Compiling...
15>Fl_Browser_.cxx
32>.\iconize_release\iconize.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
32>Done building project "iconize.vcxproj" -- FAILED.
35>------ Build started: Project: label, Configuration: Release Win32 ------
33>.\image_release\image.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
33>Done building project "image.vcxproj" -- FAILED.
36>------ Build started: Project: line_style, Configuration: Release Win32 ------
35>label.cxx
34>.\input_release\input.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
34>Done building project "input.vcxproj" -- FAILED.
37>------ Build started: Project: menubar, Configuration: Release Win32 ------
36>line_style.cxx
37>menubar.cxx
15>Fl_Browser_load.cxx
15>Fl_Button.cxx
35>.\label_release\label.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
35>Done building project "label.vcxproj" -- FAILED.
38>------ Build started: Project: message, Configuration: Release Win32 ------
36>.\line_style_release\line_style.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
36>Done building project "line_style.vcxproj" -- FAILED.
39>------ Build started: Project: minimum, Configuration: Release Win32 ------
37>.\menubar_release\menubar.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
37>Done building project "menubar.vcxproj" -- FAILED.
40>------ Build started: Project: navigation, Configuration: Release Win32 ------
15>Fl_Chart.cxx
39>minimum.cxx
40>navigation.cxx
15>Fl_Check_Browser.cxx
38>message.cxx
38>.\message_release\message.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
38>Done building project "message.vcxproj" -- FAILED.
41>------ Build started: Project: output, Configuration: Release Win32 ------
39>.\minimum_release\minimum.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
39>Done building project "minimum.vcxproj" -- FAILED.
42>------ Build started: Project: overlay, Configuration: Release Win32 ------
41>output.cxx
40>.\navigation_release\navigation.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
40>Done building project "navigation.vcxproj" -- FAILED.
43>------ Build started: Project: pack, Configuration: Release Win32 ------
15>Fl_Check_Button.cxx
43>pack.cxx
15>Fl_Choice.cxx
42>overlay.cxx
41>.\output_release\output.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>Fl_Clock.cxx
41>Done building project "output.vcxproj" -- FAILED.
44>------ Build started: Project: pixmap, Configuration: Release Win32 ------
42>.\overlay_release\overlay.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
42>Done building project "overlay.vcxproj" -- FAILED.
45>------ Build started: Project: resizebox, Configuration: Release Win32 ------
43>.\pack_release\pack.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
45>resizebox.cxx
43>Done building project "pack.vcxproj" -- FAILED.
46>------ Build started: Project: scroll, Configuration: Release Win32 ------
15>fl_color.cxx
45>.\resizebox_release\resizebox.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>Fl_Color_Chooser.cxx
45>Done building project "resizebox.vcxproj" -- FAILED.
47>------ Build started: Project: shape, Configuration: Release Win32 ------
44>pixmap.cxx
46>scroll.cxx
44>.\pixmap_release\pixmap.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
44>Done building project "pixmap.vcxproj" -- FAILED.
46>.\scroll_release\scroll.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
48>------ Build started: Project: subwindow, Configuration: Release Win32 ------
46>Done building project "scroll.vcxproj" -- FAILED.
49>------ Build started: Project: sudoku, Configuration: Release Win32 ------
47>shape.cxx
49>sudoku.cxx
15>Fl_compose.cxx
15>Fl_Copy_Surface.cxx
48>subwindow.cxx
47>.\shape_release\shape.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
47>Done building project "shape.vcxproj" -- FAILED.
50>------ Build started: Project: symbols, Configuration: Release Win32 ------
48>.\subwindow_release\subwindow.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
48>Done building project "subwindow.vcxproj" -- FAILED.
51>------ Build started: Project: threads, Configuration: Release Win32 ------
50>symbols.cxx
51>threads.cxx
15>Fl_Counter.cxx
49>.\sudoku_release\sudoku.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
49>Done building project "sudoku.vcxproj" -- FAILED.
52>------ Build started: Project: tile, Configuration: Release Win32 ------
15>fl_cursor.cxx
50>.\symbols_release\symbols.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
50>Done building project "symbols.vcxproj" -- FAILED.
53>------ Build started: Project: tiled_image, Configuration: Release Win32 ------
51>.\threads_release\threads.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
51>Done building project "threads.vcxproj" -- FAILED.
54>------ Build started: Project: checkers, Configuration: Release Win32 ------
53>tiled_image.cxx
54>checkers.cxx
52>tile.cxx
15>fl_curve.cxx
52>.\tile_release\tile.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
52>Done building project "tile.vcxproj" -- FAILED.
55>------ Build started: Project: adjuster, Configuration: Release Win32 ------
15>Fl_Dial.cxx
55>adjuster.cxx
53>.\tiled_image_release\tiled_image.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
53>Done building project "tiled_image.vcxproj" -- FAILED.
56>------ Build started: Project: arc, Configuration: Release Win32 ------
15>fl_diamond_box.cxx
56>arc.cxx
55>.\adjuster_release\adjuster.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
54>.\checkers_release\checkers.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
54>Done building project "checkers.vcxproj" -- FAILED.
57>------ Build started: Project: input_choice, Configuration: Release Win32 ------
55>Done building project "adjuster.vcxproj" -- FAILED.
58>------ Build started: Project: utf8, Configuration: Release Win32 ------
15>Fl_display.cxx
57>input_choice.cxx
58>utf8.cxx
15>fl_dnd.cxx
56>.\arc_release\arc.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
56>Done building project "arc.vcxproj" -- FAILED.
59>------ Build started: Project: table, Configuration: Release Win32 ------
59>table.cxx
57>.\input_choice_release\input_choice.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
57>Done building project "input_choice.vcxproj" -- FAILED.
60>------ Build started: Project: blocks, Configuration: Release Win32 ------
58>.\utf8_release\utf8.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
58>Done building project "utf8.vcxproj" -- FAILED.
61>------ Build started: Project: rotated_text, Configuration: Release Win32 ------
60>blocks.cxx
15>Fl_Double_Window.cxx
61>rotated_text.cxx
59>.\table_release\table.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>Generating Code...
59>Done building project "table.vcxproj" -- FAILED.
62>------ Build started: Project: device, Configuration: Release Win32 ------
61>.\rotated_text_release\rotated_text.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
61>Done building project "rotated_text.vcxproj" -- FAILED.
63>------ Build started: Project: native-filechooser, Configuration: Release Win32 ------
60>.\blocks_release\blocks.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
60>Done building project "blocks.vcxproj" -- FAILED.
64>------ Build started: Project: cairo_test, Configuration: Release Win32 ------
15>Compiling...
15>fl_draw.cxx
63>native-filechooser.cxx
64>cairo_test.cxx
15>fl_draw_image.cxx
62>device.cxx
64>.\cairo_test_release\cairo_test.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
64>Done building project "cairo_test.vcxproj" -- FAILED.
65>------ Build started: Project: unittests, Configuration: Release Win32 ------
62>.\device_release\device.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
62>Done building project "device.vcxproj" -- FAILED.
65>unittests.cxx
15>fl_draw_pixmap.cxx
63>.\native-filechooser_release\native-filechooser.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>fl_engraved_label.cxx
63>Done building project "native-filechooser.vcxproj" -- FAILED.
15>Fl_File_Browser.cxx
65>.\unittests_release\unittests.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
65>Done building project "unittests.vcxproj" -- FAILED.
15>Fl_File_Chooser.cxx
15>Fl_File_Chooser2.cxx
15>fl_file_dir.cxx
15>Fl_File_Icon.cxx
15>Fl_File_Icon2.cxx
15>Fl_File_Input.cxx
15>fl_font.cxx
15>Fl_get_key.cxx
15>Fl_get_system_colors.cxx
15>Fl_GIF_Image.cxx
15>Fl_Gl_Choice.cxx
15>Fl_Gl_Overlay.cxx
15>Fl_Gl_Window.cxx
15>Fl_grab.cxx
15>Fl_Group.cxx
15>Generating Code...
15>Compiling...
15>Fl_Help_Dialog.cxx
15>Fl_Help_View.cxx
15>Fl_Image.cxx
15>Fl_Image_Surface.cxx
15>fl_images_core.cxx
15>Fl_Input.cxx
15>Fl_Input_.cxx
15>Fl_JPEG_Image.cxx
15>fl_labeltype.cxx
15>Fl_Light_Button.cxx
15>fl_line_style.cxx
15>Fl_lock.cxx
15>Fl_Menu.cxx
15>Fl_Menu_.cxx
15>Fl_Menu_add.cxx
15>Fl_Menu_Bar.cxx
15>Fl_Menu_Button.cxx
15>Fl_Menu_global.cxx
15>Fl_Menu_Window.cxx
15>Fl_Multi_Label.cxx
15>Generating Code...
15>Compiling...
15>fl_oval_box.cxx
15>fl_overlay.cxx
15>fl_overlay_visual.cxx
15>Fl_Overlay_Window.cxx
15>Fl_own_colormap.cxx
15>Fl_Pack.cxx
15>Fl_Paged_Device.cxx
15>Fl_Pixmap.cxx
15>fl_plastic.cxx
15>Fl_PNG_Image.cxx
15>Fl_PNM_Image.cxx
15>Fl_Positioner.cxx
15>Fl_PostScript.cxx
15>Fl_Preferences.cxx
15>Fl_Progress.cxx
15>fl_rect.cxx
15>Fl_Repeat_Button.cxx
15>Fl_Return_Button.cxx
15>Fl_Roller.cxx
15>fl_round_box.cxx
15>Generating Code...
15>Compiling...
15>Fl_Round_Button.cxx
15>fl_rounded_box.cxx
15>Fl_Scroll.cxx
15>fl_scroll_area.cxx
15>Fl_Scrollbar.cxx
15>fl_set_font.cxx
15>fl_set_fonts.cxx
15>fl_shadow_box.cxx
15>Fl_Shared_Image.cxx
15>fl_shortcut.cxx
15>fl_show_colormap.cxx
15>Fl_Single_Window.cxx
15>Fl_Slider.cxx
15>fl_symbols.cxx
15>Fl_Table.cxx
15>Fl_Table_Row.cxx
15>Fl_Tabs.cxx
15>Fl_Text_Buffer.cxx
15>Fl_Text_Display.cxx
15>Fl_Text_Editor.cxx
15>Generating Code...
15>Compiling...
15>Fl_Tile.cxx
15>Fl_Tiled_Image.cxx
15>Fl_Tooltip.cxx
15>Fl_Tree.cxx
15>Fl_Tree_Item.cxx
15>Fl_Tree_Item_Array.cxx
15>Fl_Tree_Prefs.cxx
15>Fl_Valuator.cxx
15>Fl_Value_Input.cxx
15>Fl_Value_Output.cxx
15>Fl_Value_Slider.cxx
15>fl_vertex.cxx
15>Fl_visual.cxx
15>Fl_Widget.cxx
15>Fl_Window.cxx
15>Fl_Window_fullscreen.cxx
15>Fl_Window_hotspot.cxx
15>Fl_Window_iconize.cxx
15>Fl_Window_shape.cxx
15>Fl_Wizard.cxx
15>Generating Code...
15>Compiling...
15>Fl_x.cxx
15>Fl_XBM_Image.cxx
15>Fl_XPM_Image.cxx
15>forms_bitmap.cxx
15>forms_compatability.cxx
15>forms_free.cxx
15>forms_fselect.cxx
15>forms_pixmap.cxx
15>forms_timer.cxx
15>gl_draw.cxx
15>gl_start.cxx
15>glut_compatability.cxx
15>glut_font.cxx
15>screen_xywh.cxx
15>Generating Code...
15>Fl_Cairo.cxx
15>Fl_Device.cxx
15>Fl_Gl_Device_Plugin.cxx
15>fl_gtk.cxx
15>fl_gleam.cxx
15>Fl_Native_File_Chooser.cxx
15>fl_open_uri.cxx
15>Fl_Printer.cxx
15>fl_read_image.cxx
15>fl_utf8.cxx
15>freeglut_geometry.cxx
15>freeglut_stroke_mono_roman.cxx
15>freeglut_stroke_roman.cxx
15>freeglut_teapot.cxx
15>ps_image.cxx
15>Generating Code...
15>flstring.c
15>numericsort.c
15>scandir.c
15>vsnprintf.c
15>Generating Code...
15>.\fltkdll_release\case.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
15>Done building project "fltkdll.vcxproj" -- FAILED.
66>------ Build started: Project: fluid, Configuration: Release Win32 ------
67>------ Build started: Project: editor, Configuration: Release Win32 ------
67>editor.cxx
66>about_panel.cxx
66>align_widget.cxx
66>alignment_panel.cxx
67>.\editor_release\editor.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
67>Done building project "editor.vcxproj" -- FAILED.
66>code.cxx
66>CodeEditor.cxx
66>ExternalCodeEditor_WIN32.cxx
66>factory.cxx
66>file.cxx
66>Fl_Function_Type.cxx
66>Fl_Group_Type.cxx
66>Fl_Menu_Type.cxx
66>Fl_Type.cxx
66>Fl_Widget_Type.cxx
66>Fl_Window_Type.cxx
66>fluid.cxx
66>Fluid_Image.cxx
66>function_panel.cxx
66>template_panel.cxx
66>undo.cxx
66>widget_panel.cxx
66>Generating Code...
66>.\fluid_release\about_panel.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
66>Done building project "fluid.vcxproj" -- FAILED.
68>------ Build started: Project: CubeView, Configuration: Release Win32 ------
69>------ Build started: Project: fast_slow, Configuration: Release Win32 ------
70>------ Build started: Project: inactive, Configuration: Release Win32 ------
71>------ Build started: Project: keyboard, Configuration: Release Win32 ------
70>Create .cxx and .h file with fluidd
70>Compiling fluid files ...
70>'..\fluid\fluid' is not recognized as an internal or external command,
70>operable program or batch file.
69>Create .cxx and .h file with fluid
69>Compiling fluid files ...
71>Create .cxx and .h file with fluid
71>Compiling fluid files ...
68>Create .cxx and .h file with fluid
68>Compiling fluid files ...
68>'..\fluid\fluid' is not recognized as an internal or external command,
68>operable program or batch file.
71>'..\fluid\fluid' is not recognized as an internal or external command,
71>operable program or batch file.
69>'..\fluid\fluid' is not recognized as an internal or external command,
69>operable program or batch file.
69>fast_slow.cxx
70>inactive.cxx
71>keyboard.cxx
69>c1xx : fatal error C1083: Cannot open source file: '..\..\test\fast_slow.cxx': No such file or directory
70>c1xx : fatal error C1083: Cannot open source file: '..\..\test\inactive.cxx': No such file or directory
70>Done building project "inactive.vcxproj" -- FAILED.
72>------ Build started: Project: mandelbrot, Configuration: Release Win32 ------
72>Create .cxx and .h file with fluid
72>Compiling fluid files ...
72>'..\fluid\fluid' is not recognized as an internal or external command,
72>operable program or batch file.
72>mandelbrot.cxx
71>keyboard_ui.cxx
71>c1xx : fatal error C1083: Cannot open source file: '..\..\test\keyboard_ui.cxx': No such file or directory
71>Generating Code...
71>Done building project "keyboard.vcxproj" -- FAILED.
73>------ Build started: Project: preferences, Configuration: Release Win32 ------
73>Create .cxx and .h file with fluid
73>Compiling fluid files ...
73>'..\fluid\fluid' is not recognized as an internal or external command,
73>operable program or batch file.
72>mandelbrot_ui.cxx
72>c1xx : fatal error C1083: Cannot open source file: '..\..\test\mandelbrot_ui.cxx': No such file or directory
72>Generating Code...
73>preferences.cxx
73>c1xx : fatal error C1083: Cannot open source file: '..\..\test\preferences.cxx': No such file or directory
69>Done building project "fast_slow.vcxproj" -- FAILED.
74>------ Build started: Project: radio, Configuration: Release Win32 ------
73>Done building project "preferences.vcxproj" -- FAILED.
75>------ Build started: Project: resize, Configuration: Release Win32 ------
72>Done building project "mandelbrot.vcxproj" -- FAILED.
76>------ Build started: Project: tabs, Configuration: Release Win32 ------
75>Create .cxx and .h file with fluid
76>Create tabs.cxx and tabs.h file with fluid
68>CubeMain.cxx
68>CubeView.cxx
68>CubeViewUI.cxx
75>Compiling fluid files ...
75>'..\fluid\fluid' is not recognized as an internal or external command,
75>operable program or batch file.
76>Compiling fluid files ...
76>'..\fluid\fluid' is not recognized as an internal or external command,
76>operable program or batch file.
68>c1xx : fatal error C1083: Cannot open source file: '..\..\test\CubeViewUI.cxx': No such file or directory
68>Generating Code...
68>Done building project "CubeView.vcxproj" -- FAILED.
77>------ Build started: Project: valuators, Configuration: Release Win32 ------
75>resize.cxx
75>c1xx : fatal error C1083: Cannot open source file: '..\..\test\resize.cxx': No such file or directory
76>tabs.cxx
76>c1xx : fatal error C1083: Cannot open source file: '..\..\test\tabs.cxx': No such file or directory
75>Done building project "resize.vcxproj" -- FAILED.
78>------ Build started: Project: tree, Configuration: Release Win32 ------
76>Done building project "tabs.vcxproj" -- FAILED.
77>Create .cxx and .h file with fluid
77>Compiling fluid files ...
77>'..\fluid\fluid' is not recognized as an internal or external command,
77>operable program or batch file.
78>Create tree.cxx and tree.h file with fluid
78>Compiling fluid files ...
78>'..\fluid\fluid' is not recognized as an internal or external command,
78>operable program or batch file.
77>valuators.cxx
77>c1xx : fatal error C1083: Cannot open source file: '..\..\test\valuators.cxx': No such file or directory
77>Done building project "valuators.vcxproj" -- FAILED.
78>tree.cxx
78>c1xx : fatal error C1083: Cannot open source file: '..\..\test\tree.cxx': No such file or directory
78>Done building project "tree.vcxproj" -- FAILED.
79>------ Build started: Project: demo, Configuration: Release Win32 ------
79>demo.cxx
79>.\demo_release\demo.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
79>Done building project "demo.vcxproj" -- FAILED.
========== Build: 7 succeeded, 72 failed, 0 up-to-date, 0 skipped ==========

And my compiler and linker are flags are like this:

compiler:

/GS- /analyze- /W1 /Zc:wchar_t /I"." /I"..\..\zlib" /I"..\..\png" /I"..\..\jpeg" /I"../.." /Zi /Gm- /Od /Ob2 /Fd".\demo_release\vc141.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_CRT_SECURE_NO_DEPRECATE" /D "NDEBUG" /D "_WINDOWS" /D "WIN32_LEAN_AND_MEAN" /D "VC_EXTRA_LEAN" /D "WIN32_EXTRA_LEAN" /D "_VC80_UPGRADE=0x0710" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /MD /std:c++14 /Fa".\demo_release\" /EHsc /nologo /Fo".\demo_release\" /Os /Fp".\demo_release\demo.pch" /diagnostics:classic

linker:

/OUT:"../../test/demo.exe" /MANIFEST /PDB:".\demo_release\demo.pdb" /DYNAMICBASE:NO "fltk.lib" "comctl32.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltk.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkforms.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkgl.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkimages.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkjpeg.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkpng.lib" "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkzlib.lib" "C:\Program Files (x86)\fltk-1.3.4-1\test\fltkdll.lib" /DEBUG:FULL /MACHINE:X64 /NODEFAULTLIB:"libcd" /SAFESEH /INCREMENTAL:NO /PGD:"..\..\test\demo.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:".\demo_release\demo.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"..\..\lib" /TLBID:1

[Greg Ercolano]

On 05/01/17 14:52, Osman Zakir wrote:
> I cleaned it and tried to build it again, but I still get the same problem. And if it's doing a Debug configuration, then I don't know what's wrong because I have "Release" selected here.
>
> Here's my build output:

> [..snipped for now..]

>
> And my compiler and linker are flags are like this:
> compiler:
>

Hmm, I don't think I see any problems there.
The presence of /Gd and /Oy seem unnecessary x86 oriented flags, but probably ignored.

AFAIK, no special flags are needed in VS for compiling 64bit.
*But the project should have a "solution platform" setting.*
So make sure that's set to 64-bit if you want a 64bit build of fltk. See:
https://docs.microsoft.com/en-us/visualstudio/ide/how-to-configure-projects-to-target-platforms

Anyway, reviewing those C++ compiler flags:
https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-listed-alphabetically

..and going through them one at a time, just for completeness (and ignoring the /D and /I flags):

> /GS- /analyze- /W1 /Zc:wchar_t /I"." /I"..\..\zlib" /I"..\..\png" /I"..\..\jpeg"
> /I"../.." /Zi /Gm- /Od /Ob2 /Fd".\demo_release\vc141.pdb" /Zc:inline /fp:precise

/GS- -- disable buffer security checks
https://msdn.microsoft.com/en-us/library/8dbf701c.aspx

/W1 -- warning level #1 (severe warnings only, this is the default)
https://msdn.microsoft.com/en-us/library/thxezb7y.aspx

/Zc:wchar_t -- default wchar_t type
https://msdn.microsoft.com/en-us/library/dh8che7s.aspx

/Zi -- produce a .pdb file with debugging info.
Hmm, I would thing this typical only of a debug build,
but your linker flags below seem to refer to non-debug libs
(fltk.lib, fltkforms.lib.. e.g. no 'd' suffix), so not sure what to
make of that.
https://msdn.microsoft.com/en-us/library/958x11bc.aspx

/Gm- -- disables minimal rebuilds (pretty sure the presence of "-" means "disabled")
https://msdn.microsoft.com/en-us/library/kfz8ad09.aspx

/Od -- disable optimization

/Ob2 -- controls "inline" expansion. 2 is the default.
https://msdn.microsoft.com/en-us/library/47238hez.aspx

/Fd"path-to-.pdb" -- sets the pathname of the pdb file
https://msdn.microsoft.com/en-us/library/9wst99a9.aspx

/Zc:inline -- some kind of conformance flag. The default is normally off (which this is not).
https://msdn.microsoft.com/en-us/library/dn642448.aspx

/fp:precise -- floating point precision (the default)
https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

> /D "WIN32" /D "_CRT_SECURE_NO_DEPRECATE" /D "NDEBUG" /D "_WINDOWS" /D "WIN32_LEAN_AND_MEAN"
> /D "VC_EXTRA_LEAN" /D "WIN32_EXTRA_LEAN" /D "_VC80_UPGRADE=0x0710" /errorReport:prompt
> /WX- /Zc:forScope /Gd /Oy- /MD /std:c++14 /Fa".\demo_release\" /EHsc /nologo
> /Fo".\demo_release\" /Os /Fp".\demo_release\demo.pch" /diagnostics:classic

..continuing:

/WX- -- treat all warnings as errors
https://msdn.microsoft.com/en-us/library/thxezb7y.aspx

/Zc:forScope -- conformance flag, setting default C++ scoping rules for for() loops
https://msdn.microsoft.com/en-us/library/84wcsx8x.aspx

/Gd -- default setting for how '__cdecl" is handled. This is an x86 flag apparently,
so I don't think it influences a 64bit build.
https://msdn.microsoft.com/en-us/library/46t77ak2.aspx

/Oy- -- Disables omission of frame pointers (or I guess that means "enables frame pointers"?)
Again, this is an x86 oriented flag, probably not relevant for 64bit builds.
https://msdn.microsoft.com/en-us/library/2kxx5t2c.aspx

/MD -- create multithreaded DLLs using MSVCRT.lib. This, as opposed to /MT.
This is an important flag; IIRC, don't mix /MT and /MD within an app + its libs.
https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx

/std:c++14 -- Hmm, couldn't find reference for this at the above link, undocumented?
I assume it allows c++14 coding style.

/Fa"path" -- create a listing file
https://docs.microsoft.com/en-us/cpp/build/reference/fa-fa-listing-file

/EHsc -- exception handling.
https://docs.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model

/Fo"path" -- create obj files
https://docs.microsoft.com/en-us/cpp/build/reference/fo-object-file-name

/Os -- Favors small code.
https://docs.microsoft.com/en-us/cpp/build/reference/os-ot-favor-small-code-favor-fast-code

/Fp"path-to-.pch" -- sets precompiled header

/diagnostics:classic -- Hmm, couldn't find reference for this at the above link. Undocumented?

> linker:
>
> /OUT:"../../test/demo.exe" /MANIFEST /PDB:".\demo_release\demo.pdb"
> /DYNAMICBASE:NO "fltk.lib" "comctl32.lib" "kernel32.lib" "user32.lib"
> "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib"
> "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltk.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkforms.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkgl.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkimages.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkjpeg.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkpng.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\lib\fltkzlib.lib"
> "C:\Program Files (x86)\fltk-1.3.4-1\test\fltkdll.lib"
> /DEBUG:FULL /MACHINE:X64 /NODEFAULTLIB:"libcd" /SAFESEH
> /INCREMENTAL:NO /PGD:"..\..\test\demo.pgd" /SUBSYSTEM:WINDOWS
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
> /ManifestFile:".\demo_release\demo.exe.intermediate.manifest"
> /ERRORREPORT:PROMPT /NOLOGO
> /LIBPATH:"..\..\lib" /TLBID:1

OK, so the "/MACHINE:X64" is the key link flag telling VS to link this as
a 64bit application.

AFAIK, I don't /think/ any other flags are needed here; if Visual Studio
itself is in 64bit mode, it should be constructing 64bit binaries.

If you're getting errors with this compile/link combo, I can only assume
the compiler was not first set to an x64 environment (see above "Solution platform" setting).

I know for command line compiling, switching to 64bit builds involves environment
variable settings at the DOS prompt, which is done by specifying options to the
the VCVARS batch script to give you a DOS prompt with the 64bit environment enabled.

[Albrecht Schlosser]

On 01.05.2017 23:52 Osman Zakir wrote:
> I cleaned it and tried to build it again, but I still get the same
> problem. And if it's doing a Debug configuration, then I don't know
> what's wrong because I have "Release" selected here.
>
> Here's my build output:
>
> 1>------ Build started: Project: fltkzlib, Configuration: Release
> Win32 ------
> 2>------ Build started: Project: fltkjpeg, Configuration: Release
> Win32 ------

...

> 2>jdcoefct.c
> 1>zlib.vcxproj -> C:\Program Files
> (x86)\fltk-1.3.4-1\ide\VisualC2010\..\..\lib\fltkzlib.lib
> 3>------ Build started: Project: fltkpng, Configuration: Release
> Win32 ------

Okay, this looks like you're building the bundled IDE project in
fltk-1.3.4-1\ide\VisualC2010\ which only has win32 (x86) build
configurations with Visual Studio 2017 (notice: "Configuration: Release
Win32", emphasis on 'Win32').

Unless vs2107 did a *good* job converting the IDE project files this
*might* be the reason why it fails later. I never managed to convert the
bundled IDE files to a x64 build.

> 8>------ Build started: Project: ask, Configuration: Release Win32

Notice: '8>...' means this is the 8th project

> ------
> 6>forms_bitmap.cxx
> 6>forms_compatability.cxx
> 8>ask.cxx

The above line denotes the compilation of ask.cxx (8th project)

> 6>forms_free.cxx
> 6>forms_fselect.cxx
> 6>forms_pixmap.cxx
> 8>.\ask_release\ask.obj : fatal error LNK1112: module machine type
> 'X86' conflicts with target machine type 'x64'
> 8>Done building project "ask.vcxproj" -- FAILED.

... and now it fails because it wants to link in x64 mode. I don't know
for sure but this may be due to a failed conversion of the IDE project
files.

I can't help further with VS linker flags and such because I never use
VS except for building and testing FLTK.

I suggest to build new FLTK VS project files with CMake. Select the "VS
... compiler Win64" when asked. Select the highest (VS) version your
CMake version allows. If you use the CMake support shipped with VS2017 I
can't help further (I don't have VS2017 here), but it should work in a
similar way.

This suggestion is particularly useful because:

(1) FLTK 1.4.0 and later requires use of CMake anyway, so you can try
this already

(2) if you build your own IDE project(s) with CMake as well you can
refer your CMake script to use the exported FLTK CMake configuration
files and your project should build fine automatically.

Good luck!

[Osman Zakir]

I don't know how to enable the 64bit toolset on VS207 Command Prompt as there doesn't seem to be vcvarsall.bat file for it.  As for Win32, it says on Microsoft's website that despite the name, a "Win32" project can compile to both x86 and x64 binaries.  I guess the "32" is just there by convention.  Win32 is the name they give their Windows Desktop apps (they're Win32 apps).  CMake makes a distinction between Win32 and Win64, but Microsoft doesn't. 

Is there anyone who can help me get full PDB files from a CMake build of a x64 Debug build for FLTK?  Would be a great help.  Thanks.

[Osman Zakir]

Okay, I just found out where vcvarsall.bat is for VS2017.  I just used it.  I'll see how it goes now.

[Osman Zakir]

Same problem, still.  Except now it also can't find test.cxx for some reason.

[Greg Ercolano]

On 05/01/17 17:00, Osman Zakir wrote:
> Okay, I just found out where vcvarsall.bat is for VS2017. I just used it. I'll see how it goes now.

How did you invoke it, with the amd64 or amd64_x86 argument?
What was the resulting output when it opened the new DOS prompt?
(It should announce the compiler bit configuration, IIRC)

But note this for command line compiling VS, i.e. invoking
CL and LINK directly from DOS.

I'm not sure this is relevant if you're in the Visual Studio IDE.
In that context, I believe the "Solution Platform" setting is
what you'd be looking for.

> Same problem, still. Except now it also can't find test.cxx for some reason.

Sorry, without context, I don't know what that means.

What is test.cxx, and what commands/techniques were you
trying to compile it with; the IDE or from DOS with vcvarsall.bat
set to one of the 64bit targets using CL and LINK?

[Greg Ercolano]

I'll try installing VS 2017 so I can help you more directly.

Looks like I need to install an OS update first (of course)
which looks like it'll take >1 hour just to download,
let alone install.

Don't know how long the VS 2017 install will take.

[Osman Zakir]

I was able to do it with CMake within Visual Studio itself.  All you have to do is either open a folder with a CMake project in Visual Studio, or open devenv.exe with the folder with that project as an argument to it on a Developer Command Prompt (Visual Studio 2017 Developer Command Prompt).  Visual Studio will automatically start a CMake project with that. 

The CMake project generated FLTK build files, but there were one or two errors.  I was able to build it with it those files within Visual Studio after that, though.  I'll show you the CMake error files (they're attached to the post).  x64 and x86 Release and Debug both worked successfully, but I have a Partial PDB on the Debug configuration on both x86 and x64 in user programs. 

One question: When FLTK later only supports CMake builds, will it create problems when one has to later use those builds to build FLTK in Visual Studio as a separate step like I did here?  Or is this completely normal?

CMakeError_x64_Debug.log: https://1drv.ms/u/s!As6LkLqTe7Ps8AupGkDtGJ-YUxfh

CMakeError_x64_Release.log: https://1drv.ms/u/s!As6LkLqTe7Ps8Awm0yi2rpf-qRgD

CMakeError_x86_Debug.log: https://1drv.ms/u/s!As6LkLqTe7Ps8A2hAziQPnt2K6sW

CMakeError_x86_Release.log: https://1drv.ms/u/s!As6LkLqTe7Ps8A7m1Ew69SOPcpkl

For some reason, the .lib files for x64, Debug and Release went into the x64-Release > lib folder, with the Release .lib files in the Release folder in that directory and the Debug ones in the Debug folder.  For x86, they're both in the x86-Debug > lib folder in the same way (Release and Debug folders).  I don't know why that happened.

[Osman Zakir]

Note: When I say that you have to open a folder in VS with a CMake project, what I mean is that the folder has to have CMakeLists.txt file in it.  If VS sees that file, it'll use it to start a CMake project automatically. 

And here:

One question: When FLTK later only supports CMake builds, will it create problems when one has to later use those builds to build FLTK in Visual Studio as a separate step like I did here?  Or is this completely normal?

When I said, "...use those FLTK builds..." I meant to say "FLTK build files".  It would help if I could edit my original post to add this in; I only did it like this here because there's no "Edit" function.  Sorry about this. 

[Albrecht Schlosser]

On 02.05.2017 15:58 Osman Zakir wrote:
> I was able to do it with CMake within Visual Studio itself. All you
> have to do is either open a folder with a CMake project in Visual
> Studio, or open devenv.exe with the folder with that project as an
> argument to it on a Developer Command Prompt (Visual Studio 2017
> Developer Command Prompt). Visual Studio will automatically start a
> CMake project with that.

Great!

> The CMake project generated FLTK build files, but there were one or two
> errors.

According to the logs you linked below there were more than one or two
errors, but all these errors are CMake tests to determine which
functions and headers are available on a particular platform. Example:
VS doesn't have strlcpy, so the "build" fails with one error (undefined
reference). This is normal, but it's confusing if you look at the log
and see all these "errors".

> I was able to build it with it those files within Visual Studio
> after that, though. I'll show you the CMake error files (they're
> attached to the post). x64 and x86 Release and Debug both worked
> successfully, but I have a Partial PDB on the Debug configuration on
> both x86 and x64 in user programs.

It's great to read that you could build the project, but I can't help
with "I have a Partial PDB on the Debug configuration ...".

> One question: When FLTK later only supports CMake builds, will it create
> problems when one has to later use those builds to build FLTK in Visual
> Studio as a separate step like I did here? Or is this completely normal?

I'm not sure I fully understand what you mean, but I'd say: yes, this is
normal. Up to VS 2015 there was no direct CMake integration in Visual
Studio and the generation of the IDE files was an entire separate job
done by CMake. After that you could open the generated IDE files
(FLTK.sln) with VS and build the FLTK library.

Since VS 2017 Microsoft obviously integrated CMake into VS. Personally
I'm not keen on such an "integration" because nobody knows what MS
changed and how it works. We may have to try and see how it works. YMMV.

> CMakeError_x64_Debug.log: https://1drv.ms/u/s!As6LkLqTe7Ps8AupGkDtGJ-YUxfh
> CMakeError_x64_Release.log: https://1drv.ms/u/s!As6LkLqTe7Ps8Awm0yi2rpf-qRgD
> CMakeError_x86_Debug.log: https://1drv.ms/u/s!As6LkLqTe7Ps8A2hAziQPnt2K6sW
> CMakeError_x86_Release.log: https://1drv.ms/u/s!As6LkLqTe7Ps8A7m1Ew69SOPcpkl

See comments above.

> For some reason, the .lib files for x64, Debug and Release went into the
> x64-Release > lib folder, with the Release .lib files in the Release
> folder in that directory and the Debug ones in the Debug folder. For
> x86, they're both in the x86-Debug > lib folder in the same way (Release
> and Debug folders). I don't know why that happened.

Neither do I. The usual directory so far was Debug/lib or Release/lib
(IIRC), but the build files were always only for _one_ platform (x86 or
x64). That's one of the things MS might have changed / added as a feature.

> On Tuesday, May 2, 2017 at 6:28:26 AM UTC+5, Greg Ercolano wrote:
>
> I'll try installing VS 2017 so I can help you more directly.
>
> Looks like I need to install an OS update first (of course)
> which looks like it'll take >1 hour just to download,
> let alone install.
>
> Don't know how long the VS 2017 install will take.

I'd like to do this as well, but I'll be too busy during the next two
weeks to try it. Looking forward to your reports. Very much appreciated.

[Robin Rowe]

I build FLTK in VS2017 like this...

mkdir build
cd build
cmake -D WIN32=1 ..

FLTK is checking for WIN32, but that variable is no longer defined by
default with VS2017. Someone may want to change FLTK to use _WIN32 instead.

To specify x64 build...

cmake -A x64

If you launch a VS developer command prompt, you can then build all of
FLTK with this command...

msbuild FLTK.sln

By the way, I've had no success using vcvarsall.bat to build FLTK in a
Windows git bash shell.

Robin
--
Robin Rowe
Hollywood, California

[Osman Zakir]

Do I have to define the _WIN32 variable in Preprocessor Directives?  And as for the commands, like "cmake -D WIN32=1", I have to run those at the Developer Command Prompt, right?

[Osman Zakir]

Also, which folder do I make the "build" directory in?  The "fltk-1.3.4-1" folder, since that's where my CMakeLists.txt file is?  Or should I make it in the "CMake" folder within the "fltk-1.3.4-1" folder? 

On Tuesday, May 2, 2017 at 7:52:58 PM UTC+5, robinsrowe wrote:

[Greg Ercolano]

>> On Tuesday, May 2, 2017 at 7:52:58 PM UTC+5, robinsrowe wrote:
>>
>> I build FLTK in VS2017 like this...
>>
>> mkdir build
>> cd build
>> cmake -D WIN32=1 ..
>>

On 05/02/17 09:09, Osman Zakir wrote:
> Also, which folder do I make the "build" directory in?
> The "fltk-1.3.4-1" folder, since that's where my CMakeLists.txt file is?

Yes, create the build directory in the fltk folder.


PS. Please avoid top posting on the mailing list.

To avoid confusion, it's best to inline reply for context,
and trim what isn't part of the new conversation.

[Osman Zakir]

Thanks.  To add: What is the "-D" flag for?  Debug configuration?  If so, am I right in assuming that the Release configuration can be triggered with "-R"? 

[Greg Ercolano]

On 05/02/17 10:23, Osman Zakir wrote:
> Thanks. To add: What is the "-D" flag for?

Please don't top post. (see previous message)
https://en.wikipedia.org/wiki/Posting_style#Top-posting

Instead please inline or bottom post, as appropriate:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
https://en.wikipedia.org/wiki/Posting_style#Bottom-posting


The -D flag is sort of like the compiler's /D flag;
it defines options.

From the README.CMake.txt file that comes with FLTK:

---- snip

2.2 Options
--------------
Options can be specified to cmake with the -D flag:

cmake -D <OPTION_NAME>=<OPTION_VALUE>

Example:

cmake -D CMAKE_BUILD_TYPE=Debug

---- snip

Note that -D and CMAKE_BUILD_TYPE=Debug work together;
-D indicates a definition is about to be defined, and CMAKE_BUILD_TYPE=xxx
is the option being defined.

In the above example, it just happens to be setting the CMAKE_BUILD_TYPE,
one of many possible options, to "Debug" to enable debug symbols in FLTK.

The other value for that particular option is "Release", e.g.

cmake -D CMAKE_BUILD_TYPE=Release

..which enables a release build, which has no debugging symbols.

I actually mentioned that in a post from yesterday:

On 05/01/17 08:36, Greg Ercolano wrote:
> Are you trying to debug fltk? If not, then try building as a normal release
> instead of with fltk debug enabled; it'll make smaller/more efficient binaries.
> See the README.CMake.txt build options. To build a normal release, you'd want
> I think:
>
> cmake -D CMAKE_BUILD_TYPE=Release

For more info on the -D flag, refer to cmake's docs. Here's a snip from
the 'man cmake' manual page:

---- snip
-D <var>:<type>=<value>
Create a cmake cache entry.

When cmake is first run in an empty build tree, it creates a CMakeCache.txt file
and populates it with customizable settings for the project. This option may
be used to specify a setting that takes priority over the project's default value.
The option may be repeated for as many cache entries as desired.
---- snip

They call them 'cache entries', but they're basically options.

[Osman Zakir]

Alright, sorry for the confusion.

Anyway, is it possible to change the settings for where the CMake generated FLTK build files will go to through VS?  If so, how?  And with those commands you mentioned for CMake, I specify those at the Developer Command Prompt?  And is there a way to specify what files I want to give it as input, or will it know that through the CMakeLists.txt file and/or other things? 

It would be good if people quickly became familiar with how to use CMake through VS2017 so that these problems can be solved quicker. 

[Greg Ercolano]

On 05/02/17 07:38, Albrecht Schlosser wrote:
>> Don't know how long the VS 2017 install will take.
>
> I'd like to do this as well, but I'll be too busy during the next two
> weeks to try it. Looking forward to your reports. Very much appreciated.

Will probably have it working by tonight or tomorrow.

The OS updates took several passes, and finished this morning.

Now it's downloading VS 2017.

[Greg Ercolano]

On 05/02/17 11:49, Osman Zakir wrote:
> @Greg: Sorry; I only read your message just now. So I'm replying to that now.

OK, but you continue to top post. :/

> How do I specify what I want to build with CMake?
> Is there a way to tell it that? Or will it know by looking at the CMakeLists.txt file?

With respect to FLTK, or your own project?

Regarding FLTK, I'd defer to the README and other dev's input, but
my understanding is you control what to build within visual studio,
not cmake. (i.e. whether to build everything, just the libs, or just
test programs, specific libs or test programs, etc)

I know you can control this from the VS IDE, and I imagine you can control
this from the VS command line using "msbuild" or "devenv" (I'm not as familiar
with those as I am with the "cl" "link" command line compiler/linker commands)

[Greg Ercolano]

>> How do I specify what I want to build with CMake?
>> Is there a way to tell it that? Or will it know by looking at the CMakeLists.txt file?

> [..]

> Regarding FLTK, I'd defer to the README and other dev's input, but
> my understanding is you control what to build within visual studio,
> not cmake. (i.e. whether to build everything, just the libs, or just
> test programs, specific libs or test programs, etc)
>
> I know you can control this from the VS IDE, and I imagine you can control
> this from the VS command line using "msbuild" or "devenv"

Regarding the command line control of build targets, running 'msbuild /?'
seems to show you can choose which targets to build with the /target flag:

----
/target:<targets> Build these targets in this project. Use a semicolon or a
comma to separate multiple targets, or specify each
target separately. (Short form: /t)
Example:
/target:Resources;Compile
----

Looks like there are other flags to, to control e.g. how many cpus to use
for parallel building, etc. See the 'msbuild /?' docs for details.

[Osman Zakir]

I just figured out why the CMake build files were in weird locations.  It was because I wasn't opening FLTK.sln again for each platform and configuration.  If I want to build FLTK for x64 Debug, I have to open the FLTK.sln for that, and if I want to build FLTK for x64 Release, I open the FLTK.sln for that separately, and so on.  It's a headache, though.  Now it's working fine, but there's still that Partial PDB thing and I also encountered a problem in a user program in PPP2 where VS' linker all of a sudden find the .exe file it had to look at and update (for the user project's main source file).  I'm creating the project again to see if I can do it better this time.  I'm thinking maybe either I messed up or the project files themselves became corrupted or had something else happen somehow. 

By the way, one question: when FLTK drops support for non-CMake builds, will it also stop supporting user programs not built using CMake?  Or will those still be supported?  Like for example if I wanted to build a project in VS using VS' own compiler toolchain natively without CMake?  Because I still don't fully understand how to write CMakeLists.txt files for a specific project and I'd be in trouble if I had to write those for every FLTK user program I had to do. 

[Albrecht Schlosser]

On 03.05.2017 00:08 Osman Zakir wrote:

> By the way, one question: when FLTK drops support for non-CMake builds,

FLTK does not drop support for non-CMake builds - we only don't bundle
ready-to-use IDE files for Windows (Visual Studio) and MacOS (Xcode) in
our distribution. This means: the entire ide/* directory tree is gone in
FLTK 1.4.0.

Only if you work with Visual Studio (Windows) or Xcode (MacOS) will you
need to generate your own IDE files with CMake. Once the IDE files are
generated you can build FLTK with your IDE or the command line (maybe
msbuild or whatever, I don't know).

There are other build tools that use autoconf to generate the build
files (MinGW, Unix, Linux, and MacOS as well IIRC) or optionally CMake
as well.

> will it also stop supporting user programs not built using CMake? Or
> will those still be supported? Like for example if I wanted to build a
> project in VS using VS' own compiler toolchain natively without CMake?

No, don't worry, user programs are not affected. You can use your own
"hand-made" IDE files or the command line.

However if you build your own IDE files for your project with CMake you
can just refer to the FLTK CMake files that are generated by a FLTK
build and simplifiy your own project setup - but this is optional.

> Because I still don't fully understand how to write CMakeLists.txt files
> for a specific project and I'd be in trouble if I had to write those
> for every FLTK user program I had to do.

First of all, you don't need to do this (see above). But there are
examples in the FLTK documentation - please check README.CMake.txt and
maybe also README.MSWindows.txt. Note that these files may not be
up-to-date with the latest build recommendations, but hopefully you'll
get an idea.

Personally I prefer CMake for my projects. It needs some learning, but
once you know how to do it it's much easier (and faster) than creating
build files (Makefiles and/or IDE files) manually. And it's much more
flexible if you want to add a library or change compiler options for all
projects in your IDE solution.