Windows Builders: Cmake build improvements

[Russ4262]

Afternoon users of FreeCAD for WINDOWS!

I have had some frustration (lack of knowledge with too many try and fail attempts) with regard to building FreeCAD from source using the available libpacks. To provide more detail, I can say the actual compiling succeeds without issue. It has been the provision of dependencies for the new build that has been the source of mild agitation (rage... lol ).

Anyhow, after a number of searches on the forum for 'Access Violation' errors and other issues, I think the most recent finding, FreeCAD debug build with apeltauer's libpack builds release instead, mentioned by @wmayer has been the "bread of life" to my FreeCAD builds. So far, I have had success with building and running FreeCAD from source on Windows with MSVS Community 2017 and the libpacks by @Apeltaeur.

So, instead of adding a .bat file to the source distribution or the libpack, I thought how about mods to the CMakeLists.txt file. After all, that is the best place, yes? I added code to copy the required dependency folders from the libpack to the build folder, with checks and user options included.

Please check out my GH branch, CMake, for the one file changed - CMakeLists.txt. These changes are unique to the existing PR #2080 - Some minor CMake improvements. Some of the formatting issues addressed in that PR I have included in my changes.

Please review: . . . PR #2160 - Windows: Add libpack dependency install support.

UPDATE: 2019-05-08 1828 CST
This PR closed so I can clean up the commit list that was included. @Mlampert is assisting me with the task. I'll re-submit a new PR when I finish the process.
UPDATE: 2019-05-11 1350 CST
The PR has been resubmitted and improved. Please review. Local testing on Windows 10 x64 machine yields intended results. Some new options are carried out during CMake configure and generation. The install changes affect the INSTALL project output when you run it after a successful ALL_BUILD build.

Thanks,
Russell

[Kunda1]

Awesome thanks for the update!

[apeltauer]

[Russ4262]

Afternoon,
I've updated the PR for this topic. I added a few additional improvements beyond the first PR that I closed.

ping

ping

The new PR is active, PR #2160. When you have time, please checkout the suggested changes via CMake-Gui. I'd appreciate any feedback you can offer. I ran a CMake config and generate, followed by a successful ALL_BUILD and INSTALL. The result was a functional Release version of the software. Please verify, only if you have time. Thanks for all you do.

The new changes are specific to Windows libpack users.

Russell

[apeltauer]

I like your cmake changes.
But some remarks:
Would it be better to use the cmake install mechanism instead of using the copy mechanism? Personally I dont like the copy because you cant not tell if it is a debug or release build because the copy is triggered during the cmake configuration. Using the install mechanism is triggered after the compile.
What do you think?

[Russ4262]

Apeltauer,
Evening, Sir. Sorry to leave your question un-answered for so long.

Would it be better to use the cmake install mechanism instead of using the copy mechanism? Personally I dont like the copy because you cant not tell if it is a debug or release build because the copy is triggered during the cmake configuration. Using the install mechanism is triggered after the compile.
What do you think?

The current version in the PR incorporates three new options for Windows users: copy smaller dependency libpack folders to build (COPY command), copy larger bin libpack folder to build (COPY command), and install all dependencies to install directory (INSTALL command).

As for the two COPY command options, that is personally because I want to compile a debug or release build, but not package it - just test as is for correct functionality when I make changes to the source code. Including the COPY commands means the user doesn't have to copy any dependencies manually, simply set the options to ON, and the copying is done in the CMake configuration process. However, the COPY commands are off by default. I am trying to save Windows users some frustration when they want to compile a working software from source. I have had to track down and attempt many dependency related solutions to yield a reliable process for including dependencies for a build. I want to help others by adding simple options in the CMake configuration that automate the dependency inclusion process. Knowing I can (using this proposed PR) click on the FreeCAD.exe file after a build from source and have the software run without error is a great feeling.

The INSTALL commands are on by default, I think, because such a convenience was missing as far as I could tell. I am not yet knowledgeable enough in CMake to configure INSTALL for Debug or Release configurations. I am not yet knowledgeable enough in CMake to configure INSTALL commands for Debug or Release configurations.

Hope that helps.
Recommendations?

Russell

[sgrogan]

Recommendations?

I finally had some time to test. Your latest CMake branch works as described.
IMHO I think the pull request is good as is. It automates what we suggest in the forums.

The next step would be to selectively copy only the necessary stuff.
There is a CMake variable CMAKE_CONFIGURATION_TYPES that by default is set to Debug;Release;MinSizeRel;RelWithDebInfo
When using the default VS gives a Debug build when opening the .sln file, If its set to Release opening the .sln file gives a Release build.
With some if/elseif/else in CMake we should be able to copy stuff selectively. We would need a pattern matching algorithm to filter the release/debug libs. I don't know what CMake offers for this but we could call a python or powershell script to do this. Python would be more FreeCADic I have a powershell function from peterl94 that I use for packaging for the old libpack that might offer some inspiration. I can post it if your interested.

Great work!

EDIT: I haven't tested what happens if not using the 12.1.2 Libpack, do you have a check for this?

[apeltauer]

Russel you are totally right. We should make it as easy as possible to compile and run Fc. with your cmake adoption we are going the right way.
Thanks for your work.
Ps: Maybe you can have a look at the install process of cmake...

[Russ4262]

Ps: Maybe you can have a look at the install process of cmake...

I will do some further research into the INSTALL command of CMake.

The next step would be to selectively copy only the necessary stuff.
There is a CMake variable CMAKE_CONFIGURATION_TYPES that by default is set to Debug;Release;MinSizeRel;RelWithDebInfo
When using the default VS gives a Debug build when opening the .sln file, If its set to Release opening the .sln file gives a Release build.
With some if/elseif/else in CMake we should be able to copy stuff selectively. We would need a pattern matching algorithm to filter the release/debug libs. I don't know what CMake offers for this but we could call a python or powershell script to do this. Python would be more FreeCADic I have a powershell function from peterl94 that I use for packaging for the old libpack that might offer some inspiration. I can post it if your interested.

I recall seeing some pattern configuration in either the COPY or INSTALL commands for CMake. I look into this a little more. I had already created a small .bat file that separated certain files easily identified as debug versions; however, it was not recursive. It only acted on the active directory where I ran it. I would have to look into how to do recursive scans in the .bat file.

EDIT: I haven't tested what happens if not using the 12.1.2 Libpack, do you have a check for this?

I have not tested the 12.1.1 libpack response, nor do I have another operating system other than Windows to test the CMake changes proposed. I did request in the PR comment section that other OS users compile with the proposed CMakeLists.txt file if they had time, to determine if the changes had any negative affects on their builds.


If you two are supportive of the current changes, please tag the PR with a positive endorsement comment. I don't have any pull with admin developers in the CMake area to get the changes reviewed officially. Or, I don't know who is officially reviewing CMake changes on the development team. If you think we need to refine this PR some more, that is okay. I can close the PR and re-submit later.

Thanks Gentlemen,
Russell

[sgrogan]

I have not tested the 12.1.1 libpack response

I was actually thinking of the 11.x VS2013 libpacks, these are all we have for Win x32 at the moment. I will test.

I don't have any pull with admin developers in the CMake area to get the changes reviewed officially.

wmayer will review this when he has time.

Thanks for the work!