Alpha's Project exporter - added "working" CMAKE POC

[Miguel Gimenez]

The problem with asserts in bakefiles is inside EmitFlags(): Calling wxArrayString::Remove() asserts if the string does not exist.

IMHO the best solution for this issue is creating a wxLogNull object at the start of EmitFlags().

[AndrewCot]

I just stumbled across cacb's post about New plugin: Premake5 exporter (premake5cb) and as such I have added to the list of outstanding items updating the plugin from Premake4 to Premake5.

[AndrewCot]

While waiting for DAP debugger feedback I have gone back to the project exporter and made allot of progress with the CMAKE export feature.


I have  been able to take the C::B Windows workspace I use and export it to a set of CMAKE CMakeLists.txt & associated include files etc that can then be processed by CMAKE. To do this the SpellChecker & SmartIndent projects needed to be massaged by moving files and creating directories as the export was trying to create two or more CMakeLists.txt files in the one directory and as such the second one overwrote the first one as each target is output to a CMakeLists.txt file and these two projects had multiple target source files in the same root directory.

I am stuck with a "C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: file truncated" error, but  I cannot figure out which file is causing the error as it's with the codeblocks.exe link and there are allot of files being linked. Attached is the build log. The error occurs if I use the default cmake or if I produce and build using make, so I do not think it's a problem with ninja or make.

Anyone got any ideas on how I can find the root cause of the failure?

[AndrewCot]

I figured it out.

[AndrewCot]

I have successfully used the new Export plugin CMAKE facility to rebuild a working C::B setup using CMAKE from the source in the https://github.com/acotty/CodeBlocks_Unofficial_Testing repo.
The following are the simple steps I use to build C::B is using CMAKE

• Build C::B from the repo and install it
• Open the new C::B and load the CodeBlocks_Windows.workspace from the repo
• Select the File->Export project->CMakeLists.txt (WIP) menu item
• Create a src\Cmake_build directory
• Open a command prompt or a bash shell and change into the src\Cmake_build directory
• run the following two command to do the build:

    cmake  -DCMAKE_BUILD_TYPE=Release ..
    cmake --build .
If you are using a command prompt you need to add the directory where cmake.exe to the path. You may find that you need to install ninja if you have not already installed it as it is the default cmake build system

You will need to copy the following DLL's into the devel32_64 directory in order to run C::B and the plugins:

• libbz2-1.dll
• libgcc_s_seh-1.dll
• libhunspell-1.7-0.dll
• libstdc++-6.dll
• libwinpthread-1.dll
• wxmsw32u_gcc_cb.dll
• wxmsw32u_gl_gcc_cb.dll
• zlib1.dll

[ollydbg]

I have successfully used the new Export plugin CMAKE facility to rebuild a working C::B setup using CMAKE from the source in the https://github.com/acotty/CodeBlocks_Unofficial_Testing repo.
The following are the simple steps I use to build C::B is using CMAKE

• Build C::B from the repo and install it
• Open the new C::B and load the CodeBlocks_Windows.workspace from the repo
• Select the File->Export project->CMakeLists.txt (WIP) menu item
• Create a src\Cmake_build directory
• Open a command prompt or a bash shell and change into the src\Cmake_build directory
• run the following two command to do the build:

    cmake  -DCMAKE_BUILD_TYPE=Release ..
    cmake --build .
If you are using a command prompt you need to add the directory where cmake.exe to the path. You may find that you need to install ninja if you have not already installed it as it is the default cmake build system

Good work.

My silly question is: does the generated CMakeLists.txt has many hard-coded paths in it? If not, can you just add those CMakeLists.txt to your git repo, so people can use it directly? I mean just clone your git repo, and run the cmake to build the whole C::B workspace.

Thanks.

[AndrewCot]

My silly question is: does the generated CMakeLists.txt has many hard-coded paths in it? If not, can you just add those CMakeLists.txt to your git repo, so people can use it directly? I mean just clone your git repo, and run the cmake to build the whole C::B workspace.

Unfortunately the answer is yes. I need to do more work on the paths so that eventually (hopefully) remove all the hard coded paths. I am finding that CMake has so many options and it takes a while to figure out which option(s) to use to get the desired result as the CMake manual is not very intuitive for CMake noobs like me.

[sodev]

The CMake manual is not really useful for learning CMake, but it's a great reference once you know CMake. To start learning CMake, forget about policies, use the latest available version and don't care about anything before. A really good resource to learn Modern CMake is this book: Professional CMake: A Practical Guide.

[AndrewCot]

Update the code to remove the hard coded paths, but I will not be including the CMakeLists.txt and other include CMakeLists*.txt files in the GIT repo as then it just adds to the time it takes to keep everything in sync (it's bad enough with the C::B official code having so many different project files that need to be updated for a single change......).