MSVC 2019 cmake issue?

[Ian MacArthur]

This pretty much comes under the "I should know this" banner, but I'm having trouble getting cmake to generate a MSVC sln file for fltk-1.4 just now.

Now, as is well known, I'm not really an IDE sort of person, but for *reasons* I need to generate a MS binary.

No problem, I have a machine with MSVC 2019 installed (which TBH is for my kid to play with Unity and C#, so not really my thing...)

Anyway, fire up a "Developer command prompt" from MSVC and run a sensible looking (to me, anyway) cmake invocation:

cmake -G "Visual Studio 16 2019" -D CMAKE_BUILD_TYPE=Release -A x64 ..

Fails with: 

-- Configuring incomplete, errors occurred!
See also "D:/Tools/Ian/fltk-1.4/build-msvc/CMakeFiles/CMakeOutput.log".
See also "D:/Tools/Ian/fltk-1.4/build-msvc/CMakeFiles/CMakeError.log".

and no fltk.sln is created. Also says...

CMake Error at documentation/CMakeLists.txt:60 (string):
  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
  command.

Recalling that NSVC now supports cmake directly I tried that "GUI" way too, but it failed in the same way.

In the same repo., if I spin up an Msys shell and do my usual:

cmake -G "MSYS Makefiles" -D CMAKE_BUILD_TYPE=Release  ..

That all just works and builds.

What do I need to do differently for MSVC builds? I assume this generally works and I'm being foolish here...

[Ian MacArthur]

On Friday, 30 September 2022 at 10:13:11 UTC+1 Ian MacArthur wrote:

This pretty much comes under the "I should know this" banner, but I'm having trouble getting cmake to generate a MSVC sln file for fltk-1.4 just now.

<snip> 

What do I need to do differently for MSVC builds? I assume this generally works and I'm being foolish here...

So, I don't know what the "real" problem is, but I can dodge it by setting:

OPTION_BUILD_HTML_DOCUMENTATION:BOOL=OFF

Which then seems to prevent cmake from looking at  "documentation/CMakeLists.txt"  and thus avoids the issue...

   

[Ian MacArthur]

On Friday, 30 September 2022 at 10:28:17 UTC+1 Ian MacArthur wrote:

What do I need to do differently for MSVC builds? I assume this generally works and I'm being foolish here...

So, I don't know what the "real" problem is, but I can dodge it by setting:

OPTION_BUILD_HTML_DOCUMENTATION:BOOL=OFF

Which then seems to prevent cmake from looking at  "documentation/CMakeLists.txt"  and thus avoids the issue...

   

Special bonus question: having generated a working "solution" with cmake and built it in MSVC, I get a nice, working, 64-bit build.

But I can't persuade it to do a 32-bit build - is that not a thing any more? 

If I go into the "Configuration Manager" there is no option for a 32-bit target, only for 64-bit.

My recollection, from Long Ago, was that there used to be 32-bit option in the drop-down, too.

Maybe that went away with Win11?

Though, I'm not sure I even need a 32-bit version, TBH, so probably not that important...

 

[Ian MacArthur]

On Friday, 30 September 2022 at 11:31:57 UTC+1 Ian MacArthur wrote:

Special bonus question: having generated a working "solution" with cmake and built it in MSVC, I get a nice, working, 64-bit build.

But I can't persuade it to do a 32-bit build - is that not a thing any more? 

So... if I start the developer shell in "x86 Native Tools" mode, and then generate with 

      cmake -G "Visual Studio 16 2019" -D CMAKE_BUILD_TYPE=Release -A Win32 ..

I can get a usable 32-bit Windows sln out of it.

Still have to dodge the HTML doc generation mind you but thereafter all seems to be fine!

[Albrecht Schlosser]

On 9/30/22 11:13 Ian MacArthur wrote:

This pretty much comes under the "I should know this" banner, but I'm having trouble getting cmake to generate a MSVC sln file for fltk-1.4 just now.

Seems you *know* this, but sorry, the failed build is my fault. See below.

Now, as is well known, I'm not really an IDE sort of person, but for *reasons* I need to generate a MS binary.

No problem, I have a machine with MSVC 2019 installed (which TBH is for my kid to play with Unity and C#, so not really my thing...)

Anyway, fire up a "Developer command prompt" from MSVC and run a sensible looking (to me, anyway) cmake invocation:

cmake -G "Visual Studio 16 2019" -D CMAKE_BUILD_TYPE=Release -A x64 ..

I'm always using the default build w/o `-A ...` because I can never remember the allowed attribute values (same as for `-T ...`, BTW). But this has nothing to do with the build failure.

Fails with: 

-- Configuring incomplete, errors occurred!
See also "D:/Tools/Ian/fltk-1.4/build-msvc/CMakeFiles/CMakeOutput.log".
See also "D:/Tools/Ian/fltk-1.4/build-msvc/CMakeFiles/CMakeError.log".

and no fltk.sln is created. Also says...

CMake Error at documentation/CMakeLists.txt:60 (string):
  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
  command.

This looks like CMake can't retrieve the doxygen version, resulting in one argument of the `string (REGEX REPLACE ...` command being empty. This should be checked in the CMake file. Thanks for your report, I'll look into it...

Recalling that NSVC now supports cmake directly I tried that "GUI" way too, but it failed in the same way.

That's no surprise but thanks for trying it.

In the same repo., if I spin up an Msys shell and do my usual:

cmake -G "MSYS Makefiles" -D CMAKE_BUILD_TYPE=Release  ..

That all just works and builds.

Maybe the MSYS build finds doxygen?

What do I need to do differently for MSVC builds? I assume this generally works and I'm being foolish here...

No, don't worry, it's not your fault. You *shouldn't* have to do anything differently, except the system specific build options, of course.

That said, just for my information: can you please tell me if doxygen was found in *both* builds? You can post the output of the following command in the respective build directories (the output below is from my Linux system):

$ grep '^DOXYGEN' CMakeCache.txt 
DOXYGEN_DOT_EXECUTABLE:FILEPATH=/usr/bin/dot
DOXYGEN_EXECUTABLE:FILEPATH=/usr/local/doxygen-1.9.1/bin/doxygen
DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1

Note: DOXYGEN in capitals, or use 'grep -i'.

TIA

[imm]

On Fri, 30 Sept 2022 at 16:43, Albrecht Schlosser wrote:
>
> I'm always using the default build w/o `-A ...` because I can never remember the allowed attribute values (same as for `-T ...`, BTW). But this has nothing to do with the build failure.
>

FWIW, in the "standard"development shell, then "-A x64" seems to give
me a 64-bit sln.
In the "x86 Native" shell, then "-A Win32" seems to yield a 32-bit sln.

> Maybe the MSYS build finds doxygen?

AFAICT, both shells have DOXYGEN in the path.

>
> That said, just for my information: can you please tell me if doxygen was found in *both* builds? You can post the output of the following command in the respective build directories (the output below is from my Linux system):

For a (32-bit) mingw run, I get:

$ grep DOXYGEN CMakeCache.txt
DOXYGEN_DOT_EXECUTABLE:FILEPATH=DOXYGEN_DOT_EXECUTABLE-NOTFOUND
DOXYGEN_EXECUTABLE:FILEPATH=D:/Programs/doxygen/bin/doxygen.exe
//ADVANCED property for variable: DOXYGEN_DOT_EXECUTABLE
DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DOXYGEN_EXECUTABLE
DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1


For a (32-bit) VS2019 run I get:

DOXYGEN_DOT_EXECUTABLE:FILEPATH=DOXYGEN_DOT_EXECUTABLE-NOTFOUND
DOXYGEN_EXECUTABLE:FILEPATH=D:/Programs/doxygen/bin/doxygen.exe
//ADVANCED property for variable: DOXYGEN_DOT_EXECUTABLE
DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DOXYGEN_EXECUTABLE
DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1

Basically the same for both (equivalent 64-bit runs also match this...)
This result seems about right, since I do not have dot installed, only doxygen.

HOWEVER:
The MSVC (VS2019) developer shell does not have a valid path that
finds doxygen though, e.g.:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>doxygen
'doxygen' is not recognized as an internal or external command,
operable program or batch file.

Whereas the Msys shell does.

So cmake must be "finding" my doxygen "somehow" in the msvc runs,
using cmake magic (I sometimes wish it would not do that...).


If I invoke doxygen with the path cmake finds, within the msvc dev
shell, it does work (forward slashes notwithstanding):

C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community>D:/Programs/doxygen/bin/doxygen.exe -v
1.9.4 (5d15657a55555e6181a7830a5c723af75e7577e2)

So the build should be able to invoke doxygen OK I think.

[Albrecht Schlosser]

On 9/30/22 19:09 imm wrote:
> On Fri, 30 Sept 2022 at 16:43, Albrecht Schlosser wrote:
>> I'm always using the default build w/o `-A ...` because I can never remember the allowed attribute values (same as for `-T ...`, BTW). But this has nothing to do with the build failure.
>>
> FWIW, in the "standard"development shell, then "-A x64" seems to give
> me a 64-bit sln.
> In the "x86 Native" shell, then "-A Win32" seems to yield a 32-bit sln.

Yes, something like that, thanks. But I'll forget this again since it's
Windows stuff ... ;-)

>> Maybe the MSYS build finds doxygen?
> AFAICT, both shells have DOXYGEN in the path.

OK ...

> For a (32-bit) mingw run, I get:
>
> $ grep DOXYGEN CMakeCache.txt
> DOXYGEN_DOT_EXECUTABLE:FILEPATH=DOXYGEN_DOT_EXECUTABLE-NOTFOUND
> DOXYGEN_EXECUTABLE:FILEPATH=D:/Programs/doxygen/bin/doxygen.exe
> //ADVANCED property for variable: DOXYGEN_DOT_EXECUTABLE
> DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
> //ADVANCED property for variable: DOXYGEN_EXECUTABLE
> DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1
>
>
> For a (32-bit) VS2019 run I get:
>
> DOXYGEN_DOT_EXECUTABLE:FILEPATH=DOXYGEN_DOT_EXECUTABLE-NOTFOUND
> DOXYGEN_EXECUTABLE:FILEPATH=D:/Programs/doxygen/bin/doxygen.exe
> //ADVANCED property for variable: DOXYGEN_DOT_EXECUTABLE
> DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
> //ADVANCED property for variable: DOXYGEN_EXECUTABLE
> DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1
>
> Basically the same for both (equivalent 64-bit runs also match this...)
> This result seems about right, since I do not have dot installed, only doxygen.

OK, that looks fine.

> HOWEVER:
> The MSVC (VS2019) developer shell does not have a valid path that
> finds doxygen though, e.g.:
>
> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>doxygen
> 'doxygen' is not recognized as an internal or external command,
> operable program or batch file.
>
> Whereas the Msys shell does.
>
> So cmake must be "finding" my doxygen "somehow" in the msvc runs,
> using cmake magic (I sometimes wish it would not do that...).

I believe it depends on how you invoke CMake and (maybe) what shell and
path are active at that time. Unless CMake uses yet another "magic"
somehow. It's also (IMHO, maybe, ?) noteworthy that the CMake generator
should use the correct {backward | forward} slash type.

> If I invoke doxygen with the path cmake finds, within the msvc dev
> shell, it does work (forward slashes notwithstanding):
>
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community>D:/Programs/doxygen/bin/doxygen.exe -v
> 1.9.4 (5d15657a55555e6181a7830a5c723af75e7577e2)
>
> So the build should be able to invoke doxygen OK I think.

Yes, I agree, it should. I'm working on a fix and let you know when it's
ready.

[Albrecht Schlosser]

Ian, please try if git commit 5646522985896c21ff24c2552f9111091371c547
fixes the issue for you. I fixed two issues where special configurations
like yours (e.g. doxygen available but not in the PATH) could cause an
error.

[imm]

On Mon, 3 Oct 2022 at 10:19, Albrecht Schlosser wrote:
>
> Ian, please try if git commit 5646522985896c21ff24c2552f9111091371c547
> fixes the issue for you. I fixed two issues where special configurations
> like yours (e.g. doxygen available but not in the PATH) could cause an
> error.

Yes - seems fine (once I remembered to turn HTML generation bake on in
the config...!)
Tried the 32-bit and 64-bit builds, both OK.

Both produce this warning:

2>Converting Doxyfile to current doxygen version
2>CUSTOMBUILD : warning : Tag 'CLASS_DIAGRAMS' at line 1331 of file
'-' has become obsolete.
2> This tag has been removed.
2>Building Custom Rule D:/Tools/Ian/fltk-1.4/documentation/CMakeLists.txt
2>Generating HTML documentation
2>Done building project "html.vcxproj".

But seem otherwise happy. A cursory scan through the generated docs looks fine.

[Albrecht Schlosser]

On 10/3/22 11:48 imm wrote:
> On Mon, 3 Oct 2022 at 10:19, Albrecht Schlosser wrote:
>> Ian, please try if git commit 5646522985896c21ff24c2552f9111091371c547
>> fixes the issue for you. I fixed two issues where special configurations
>> like yours (e.g. doxygen available but not in the PATH) could cause an
>> error.
> Yes - seems fine (once I remembered to turn HTML generation bake on in
> the config...!)

;-)

> Tried the 32-bit and 64-bit builds, both OK.

Thanks for confirmation.

> Both produce this warning:
>
> 2>Converting Doxyfile to current doxygen version
> 2>CUSTOMBUILD : warning : Tag 'CLASS_DIAGRAMS' at line 1331 of file
> '-' has become obsolete.
> 2> This tag has been removed.
> 2>Building Custom Rule D:/Tools/Ian/fltk-1.4/documentation/CMakeLists.txt
> 2>Generating HTML documentation
> 2>Done building project "html.vcxproj".
>
> But seem otherwise happy. A cursory scan through the generated docs looks fine.

This is a well known doxygen issue. They add and remove config variables
regularly in every new doxygen release and warn if the config file
contains obsolete tags. My strategy is to keep a config version that is
not from the "latest" doxygen to be as compatible as possible with older
user doxygen versions. Sometimes we can comment out old tags to prevent
warnings but this needs some work (is the tag *used* in the older
doxygen release, do we set a value other than the default, etc.). Our
current file is based on 1.5.5 but some old tags have been commented out.

We could likely suppress these warnings entirely but for now they appear
only at configuration time (i.e. only once) rather than at build time
which seemed like a good compromise. I don't want to miss important
warnings or even error messages.

[Manolo]

For information, here is what I see now with CMake under macOS :

- if Doxygen is not on the computer, build works but "make html" cannot be done;

- if Doxygen is present as a macOS app (a bunde) in /Applications, CMake finds it inside the bundle

and "make html" works;

- if Doxygen is present as a homebrew package, CMake also finds it.

That's all very good.

[Albrecht Schlosser]

Yep, that's as it is intended. Thanks for testing and for the report.