CMake based build produces executable with more dependencies about winflexbison

[Croydon]

If I remember correctly @Croydon made CMake files for win_flex_bison and this restriction was there initially.

No, actually it was you who created the CMake files with this restriction 😄

b28ac46#diff-af3b638bc2a3e6c650974192a53c7291R5

[geoffmcl]

@lexxmark,

To do this you can switch to use Windows STATIC runtime libs...

As an CMake OPTION -

#------------------------------------------------------------------------
# Static Windows Runtime
#   Option to statically link to the Windows runtime. Maybe only 
#   applies to WIN32/MSVC.
#------------------------------------------------------------------------
if (MSVC)
    option( USE_STATIC_RUNTIME "Set ON to change /MD(DLL) to /MT(static)" OFF )
    if (USE_STATIC_RUNTIME)
        set(CompilerFlags
            CMAKE_CXX_FLAGS
            CMAKE_CXX_FLAGS_DEBUG
            CMAKE_CXX_FLAGS_RELEASE
            CMAKE_C_FLAGS
            CMAKE_C_FLAGS_DEBUG
            CMAKE_C_FLAGS_RELEASE
            )
        foreach(CompilerFlag ${CompilerFlags})
            string(REPLACE "/MD" "/MT" ${CompilerFlag} "${${CompilerFlag}}")
        endforeach()    
        message(STATUS "Using /MT STATIC runtime")
    else ()
        message(STATUS "Using /MD DYNAMIC runtime")
    endif ()
endif ()

Have done this in my fork, https://github.com/geoffmcl/winflexbison, in the win10-x64 branch, and could create a Pull Request, if desired...

HTH

[GitMensch]

Hm, @geoffmcl does this remove the need to install the VC runtime? if it doesn't then there may not be much reason to (as the runtime dlls would still need to have been installed on the system).

In any case: if the project files have those switches applied the PR would be useful; both @lexxmark and me don't know much about CMAKE + VS, there may be a direct option (at least now, as we use "newer cmake environments" - @Croydon any insights)?

[geoffmcl]

@GitMensch it certainly does ... ;=))

Compare a CMake build without it -

G:\F\Projects\winflexbison\bin\Release>dumpbin /DEPENDENTS win_flex.exe
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file win_flex.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    WS2_32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    KERNEL32.dll

  Summary - removed...

And then my fork build -

G:\F\Projects\winflex-fork\bin\Release>dumpbin /DEPENDENTS win_flex.exe
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file win_flex.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    WS2_32.dll
    KERNEL32.dll

  Summary - removed...

Chaulk and Cheese ;=))

... don't know much about CMAKE + VS ...

Ok, that explains some rather weird, unnessessary, ... and some missing... things in the CMakeLists.txt files... ;=))

Like why set CMAKE_CXX_FLAGS_XXX vars, in what seems like a C project anyway, why add -D_DEBUG to Debug, or setting Output variables, etc... CMake has good defaults for each of these things...

And missing, in add_executable(${name}...), there is no set_target_properties(${name} PROPERTIES DEBUG_POSTFIX d), to separate the Debug build...

Anyway, these are not particularly a problem... so no problem, really... just saying...

[GitMensch]

@geoffmcl I suggest to start a PR for any cmake related issues you see (however you like either "split" or one combined one). Ideally @Croydon can comment on those, too.

Ideally we also get at least one environment running via cmake that uses Mingw as those should allow us to run tests at least in this environment (so far we only build Bison and Flex); but this one really should be a separated PR :-)

[geoffmcl]

@GitMensch added PR #52, for at least the STATIC runtimes....

Will hold off on other suggestions, for now... and further feedback...

And yes, it should be easily possible to build a Mingw version, using CMake... I do it now and then with other projects...

I am presently struggling with where/how to install win_flex, and win_bison, with its dependence on a data directory, and maybe other dirs, as subs of where it is run from... ugh...

Other packages use like C:\Users\<user>\AppData\Roaming\<package> for such additional stuff... has this been considered? I am still considering, exploring, etc... but would appreciate any further feedback... thanks..

[lexxmark]

Hi there,

Sorry for delay and thank you guys for help and clarification.

I will use STATIC switcher to prepare releases, because the initial idea was to have as minimum dependencies as possible.

I am presently struggling with where/how to install win_flex, and win_bison, with its dependence on a data directory, and maybe other dirs, as subs of where it is run from... ugh...

"data" sub-directory is a part of original GNU bison project and win_bison behaves in a similar way.
I consider "data" files as resources, they usually goes with executables.
I didn't see any problems with this until your note. win_bison looks for "data" subfolder in the folder where executable live - this covers 99.9% of cases. You can change this by setting BISON_PKGDATADIR environment variable (I updated changelog to reflect such possibility).

Other packages use like C:\Users<user>\AppData\Roaming<package> for such additional stuff... has this been considered?

User specific locations used for user specific data usually. As I said in our case it's more similar to resource files.

Any comments/suggestions on this are appreciated

[geoffmcl]

@lexxmark certainly agree with the idea of releasing Windows binary EXE files, with the minimum of dependencies as possible... if you are prepared for the extra effort... like using the STATIC switcher proposed... PR #52...

But do not always do it myself ;=(( since the MSVC runtimes is free download and install...

In addition, as another alternative, is to build using MingW/Mingw-w64 - which I again sometimes do - but wonder why you restrict this with, in root CMakeLists.txt -

if(NOT MSVC)
   message( FATAL_ERROR "Visual Studio Build supported only" )
endif()

However, I tried changing that to only a WARNING and the cmake generation of -G "MinGW Makefiles" seemed to work ok, but the tool mingw32-make failed with -

...
[  0%] Building C object common/CMakeFiles/common_lib.dir/m4/builtin.c.obj
cd /d G:\F\Projects\winflex-fork\temp-mingw.x64\common && D:\mingw-w64\mingw64\bin\gcc.exe -D_CRT_SECURE_NO_WARNINGS -D_LIB @CMakeFiles/common_lib.dir/includes_C.rsp -O3 -DNDEBUG   -o CMakeFiles\common_lib.dir\m4\builtin.c.obj   -c G:\F\Projects\winflex-fork\common\m4\builtin.c
In file included from G:\F\Projects\winflex-fork\common\m4\m4.h:40:0,
                 from G:\F\Projects\winflex-fork\common\m4\builtin.c:26:
G:/F/Projects/winflex-fork/common/m4/lib/clean-temp.h:110:13: error: conflicting types for 'mode_t'
 typedef int mode_t;
             ^
In file included from D:/mingw-w64/mingw64/x86_64-w64-mingw32/include/sys/stat.h:26:0,
                 from G:\F\Projects\winflex-fork\common\m4\m4.h:36,
                 from G:\F\Projects\winflex-fork\common\m4\builtin.c:26:
D:/mingw-w64/mingw64/x86_64-w64-mingw32/include/sys/types.h:77:17: note: previous declaration of 'mode_t' was here
 typedef _mode_t mode_t;
                 ^
common\CMakeFiles\common_lib.dir\build.make:65: recipe for target 'common/CMakeFiles/common_lib.dir/m4/builtin.c.obj' failed
mingw32-make[2]: *** [common/CMakeFiles/common_lib.dir/m4/builtin.c.obj] Error 1
mingw32-make[2]: Leaving directory 'G:/F/Projects/winflex-fork/temp-mingw.x64'
...

Have not yet looked at it deeply, but seem it could be fixed... if I get the time... but why the restriction? Is there something else I am missing?

Yes, thanks for the BISON_PKGDATADIR environment variable... glancing at the code, that should work... but there is still a question where to put, and point, this variable...

I have a simple path, C:\mdos - historic name - which is in my PATH... it is where I put MANY GNU tools, like grep, tail, etc, etc... but it is not very convenient to dump say your win_flex_bison-2.5.22.zip there...

That ZIP has things like changelog.md, FlexLexer.h, README.md, UNISTD_ERROR.readme, ... dropped into the root... which is just not convenient to put those in that directory too... hence the ugh ;=))

And yes, I accidentally suggested %AppData% - that is a per user - that is wrong for this data... just a slip-up...

I meant the hidden %ProgramData% junction - ie like %ProgramData%\bison...

It seems that would be a closer Windows equivalent to the /usr/share/bison I see in unix... but there are probably many other opinions, options... on this...

Anyway, just, hopefully, helpful suggestions...

Meantime I have installed your ZIP in G:\Z\bin, and adjust the PATH locally to match...

This all started because I was trying to build wireshark, in Windows, with MSVC... but am now stuck with the generated ascend.c fails to compile! oh, well... ever onwards...

[lexxmark]

Have not yet looked at it deeply, but seem it could be fixed... if I get the time... but why the restriction? Is there something else I am missing?

If I remember correctly @Croydon made CMake files for win_flex_bison and this restriction was there initially. I guess this check just limits tested environments/compilers. If we manage to fix mingw toolchain, we could remove or loose this restriction.

Yes, thanks for the BISON_PKGDATADIR environment variable... glancing at the code, that should work... but there is still a question where to put, and point, this variable...

This environment variable (like PATH) that points to "\data" folder (if it is not in win_bison.exe folder). So you can place "\data" folder in more appropriate place at installation and make a system environment variable BISON_PKGDATADIR to point to this folder. Or set local BISON_PKGDATADIR every time you call win_bison.exe

I have a simple path, C:\mdos - historic name - which is in my PATH... it is where I put MANY GNU tools, like grep, tail, etc, etc... but it is not very convenient to dump say your win_flex_bison-2.5.22.zip there..

I see the point now. That make sense. Does other tools grep, tail... have zip file or installation that just have only exe files? Could you give me an example.

It seems that would be a closer Windows equivalent to the /usr/share/bison I see in unix... but there are probably many other opinions, options... on this...

Zip archive itself cannot put "\data" folder into "%ProgramData%\bison" or wherever. So I guess you are talking about conan/chocolatey install scripts. Am I right?

This all started because I was trying to build wireshark, in Windows, with MSVC
As I remember wireshark documentation advises to install win_flex_bison using chocolatey package manager. This installation should be smooth.

[lexxmark]

@Croydon Sorry, my fault - it seems I made cmake config files using some template that had such a restricton.

[GitMensch]

We found out that the difference is because of the different build environment and that the standard for the existing projects (static linking of VS-Runtime) is reasonable.
As this can be optionally forced for the CMake generated builds now, too and I've adjusted the CI-generated builds to use this option (because the purpose is to extract and use those to get the most current one) this issue can be closed.

Some future date someone should merge the changes of master to the 2.7 branch but this isn't reasonable if there are no other changes there (which currently isn't the case) [sole exception: if @geoffmcl finishes the MinGW build, providing a completely new target].

[geoffmcl]

@lexxmark, @Croydon, @GitMensch, thank you for the additional feedback, merge, and information...

Of course, do not agree with the removal of the second message(...) output, but no time to argue the case... is not a problem... it was just informational anyway... sad, but ok...

Yes, the fact that you use a simple ZIP format to distribute your releases is a bit of a problem, since bison, at least, requires access to additional data at run time...

And this is not the case for the small number of unix utils for window, that I use... but I do now note they do include flex and bison, but add the data on another usr/local/share path in their zip... while the EXE's are usr/local/wbin...

So, the windows user must be savvy enough to unzip your ZIP somewhere appropriate, typically say C:\Program Files\flexbison, or somewhere else, like in my case, G:\Z\bin, and add that path to PATH environent variable... to use the tools in a command prompt... and have the tools, and their data, if any, found through say FindLEX.cmake and FindYACC.cmake, as used in say wireshark...

Another alternative to ZIP distribution, are Windows installers, like NSIS, Chocolatey, vcpkg, etc, etc, etc... which can do all/most of the above steps for the user... have used some of these... with reasonable succeess... but this is somewhat unusual for command line apps, but not unheard of... 7-zip being one, in C:\Program Files\7-Zip\7z.exe...

And this sort of overloads the PATH environment... in my case it is already about 2K in length, some 50 paths... but very possible...

So, yes, I have been eyeing the Choclatey system for years, but as of now have not installed it... not sure why, since it now supports over 7,000 packages... will probably bite that bullet one day...

Concerning a MinGW[-w64] build, with just a few very minor source changes, under a __MINGW32__ flag, got 99% there, but ran into a problem with timespec_get(&ts, TIME_UTC);, in getrxtime.c, seemingly NOT yet supported by mingw-w64... even though I updated my installation from 5.3.0, to what I think is the latest, 8.1.0... it is missing from their substituted version of <time.h>, and thus presumably not in the runtime libraries provided...

It would be possible to code a __MINGW32__ substitute... but sort of got exhausted... any ideas on this would be welcome...

HTH...
Edit: Fix Mingw flag

[GitMensch]

Just a note: I've rechecked with current MSYS2 - doesn't build at all with cmake (neither msys nor mingw32 target) because of m4/builtin.c + regex; did I do something wrong?