windres cannot find "wx/msw/wx.rc" building wxWidgets project with MSYS2-minGW64 and Codelite - wxwidgets

Opening a new questions as some older answer does not apply to my case.
As per subject, I cannot compile a basic wxWidgets "Hello, World" program in Windows 10 with CodeLite 14 and wxWidgets 3.1.4 (compiled using MSYS2-mingW64).
The error message is at line
C:/Users/Federico/codelite/wxHelloWorld/win_resources.rc:1:10: fatal error: wx/msw/wx.rc: No such file or directory
1 | #include "wx/msw/wx.rc"
| ^~~~~~~~~~~~~~
compilation terminated.
The resource file flags returned by wx-config running wx-config --rcflags are:
--use-temp-file --define __WXMSW__ --define _UNICODE --include-dir C:/wx/3.1.4-msys/lib/gcc_lib/mswu --include-dir C:/wx/3.1.4-msys/include
All folders/files are properly in place. By tinkering with these flags I found that no errors are given, and the program is properly compile, if I remove the --use-temp-file flag, like:
--define __WXMSW__ --define _UNICODE --include-dir C:/wx/3.1.4-msys/lib/gcc_lib/mswu --include-dir C:/wx/3.1.4-msys/include
Then everything works. Unfortunately, that flag is assumed by default by wx-config, so the only easy solution to not have it would be to just stop using wx-config and manually configure all compiler flags. So:
Is there any ways I could avoid this?
What is that flag meant for?

This is really strange because the use of --use-temp-file was removed from wx makefiles in the commit 093c3067e8 (Don't use windres --use-temp-file option, 2020-07-13) which is part of 3.1.4, so you shouldn't be seeing it at all.
But wait, it's even stranger, because wx-config doesn't have --rcflags option that you apparently use. It does have --rescomp option, but it has never included --use-temp-file in its output at all, AFAICS, and definitely not in 3.1.4.
So it looks like you're using something other than the official 3.1.4 version. And the answer to your first question is to use the official sources instead.

Related

CMake with Emscripten and vcpkg can't bind two TOOLCHAIN_FILES

Both vcpkg and Emscripten require to set CMAKE_TOOLCHAIN_FILE to
vcpkg/scripts/buildsystems/vcpkg.cmake and emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake respectively.
How do i do that? or what is the best way to get them both working together?
right now i have a naive attempt:
set(CMAKE_TOOLCHAIN_FILE "/Users/screen-photo-to-text/vcpkg/scripts/buildsystems/vcpkg.cmake" "/Users/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake")
But it get Could not find toolchain file error and i can't find a way to get this working
To my delight, recently vcpkg received Emscripten support - see PR.
One can install packages like so:
vcpkg install zlib:wasm32-emscripten
Usage is pretty usual standard, for example CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
project(zpipe CXX)
find_package(ZLIB REQUIRED)
add_executable(zpipe zpipe.cpp)
target_link_libraries(zpipe ZLIB::ZLIB)
The tricky part is still as in question how to combine two toolchains. This invocation works for me:
mkdir build
cd build
emcmake "c:\Program files\CMake\bin\cmake" .. "-G" "Ninja" "-DCMAKE_MAKE_PROGRAM=F:/vcpkg/downloads/tools/ninja/1.10.1-windows/ninja.exe" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=%EMSDK%/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake" "-DVCPKG_TARGET_TRIPLET=wasm32-emscripten" "-DCMAKE_TOOLCHAIN_FILE=F:/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_BUILD_TYPE=Release"
emmake ninja
As usually, this needs first Emscripten environment variables set (e.g. with emsdk_env.bat).
Failing to provide this asked second toolchain will result with errors like wasm-ld: error: unknown argument: --out-implib
If for whatever reason (e.g. not absolute path) emcmake can't find the CMake executable, it may result with errors like FileNotFoundError: [WinError 2] The system cannot find the file specified
In case of CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set., as hinted, the CMAKE_MAKE_PROGRAM needs to be set pointing to ninja executable.

How to get Eclipse CDT working with WxWidgets under windows?

wxWidgets-3.1.3
Eclipse IDE 4.14.0
Eclipse CDT 9.10.0.2019x (the latest packages as of 2/2/2020)
MinGW compiler, installed via MSYS2
Windows 10 Pro
I have been using Eclipse for years for PHP, Python, JavaScript, and lua. I am, however, new to C++ and Eclipse CDT. I've got a reasonable enough grip on C++ syntax and convention that I'm ready to move on to the reason I came to C++, which is GUI. At first I tried Code::Blocks, which seemed simpler (I like wizards!), but I really would prefer an IDE with git integration, and I realised C::B didn't have that before I managed to get compilation working. So, back to Eclipse.
So far, I have done the following:
added the MinGW compiler path to %PATH%
successfully compiled wxWidgets 3.1.3 using SHARED=0 UNICODE=1 MONOLITHIC=0 BUILD=release, these changes made in %WXDIR%\build\msw\config.gcc. The various tutorials I have found wildly disagree on these parameters, but the various responses to people with my problem here and on other forums have all been generally in agreement on them, and with the exception of BUILD, they're the defaults. So.
successfully compiled a test program from samples/minimal. The resulting executable runs without needing any other DLLs in the same directory.
Unfortunately, this is where I'm stuck. There are plenty of tutorials and forum posts out there, but I run into one or more of the following problems:
Not newbie accessible. "Add a link to your wxWidgets directory" but okay, how do I do that, and do you mean the main %WXDIR% code directory or %WXDIR%\lib or what?
Don't work. "Just File->Import->File System->%WXDIR%" and nope. Did, in fact, get rid of the "not resolved" for SOME references in code pasted from "minimal.cpp", but not all.
Explicitly refer to versions of the IDE or Code from, oh, say, ten years ago, and/or contain instructions that cannot be followed in the current version.
Alternately, I would take a recommendation for another GUI toolkit that has accessible instructions for getting the current version of itself working with the current version of Eclipse.
I'll show how to compile the wxWidgets minimal sample with MinGW and eclipse. First of all, I highly recommend that you build both a debug and a release version of the wxWidgets library. These directions will assume that is the case. I'm not an expert with eclipse, so I can't guarantee these are the best directions. These directions do work for me, but corrections and improvements are welcome.
There are many, many steps here. But if you get a working project with the minimal sample, you can copy the project and change the code files to use it for further projects.
Before we do anything else, define the WXWIN environment variable in eclipse if it not already defined. From the menu select Window->Preferences->C/C++->Build->Environment, and the press the add button to add the variable.
The easiest way to build the minimal sample that comes with the library is with the command line. To do this, simply change to the WXWIN\samples\minimal folder and enter the exact same command you used to build the library. Since the command given above was mingw32-make -f makefile.gcc SHARED=0 UNICODE=1 MONOLITHIC=0 BUILD=release, this will result if the following commands being executed in the shell:
windres --use-temp-file -i../../samples/sample.rc -ogcc_mswu\minimal_sample_rc.o --define __WXMSW__ --define NDEBUG --define _UNICODE --include-dir .\..\..\lib\gcc_lib\mswu --include-dir ./../../include --include-dir . --include-dir ./../../samples --define NOPCH
g++ -c -o gcc_mswu\minimal_minimal.o -O2 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -I.\..\..\lib\gcc_lib\mswu -I.\..\..\include -W -Wall -I. -I.\..\..\samples -DNOPCH -Wno-ctor-dtor-privacy -MTgcc_mswu\minimal_minimal.o -MFgcc_mswu\minimal_minimal.o.d -MD -MP minimal.cpp
g++ -o gcc_mswu\minimal.exe #gcc_mswu\minimal.exe.rsp -mthreads -L.\..\..\lib\gcc_lib -Wl,--subsystem,windows -mwindows -lwxmsw31u_core -lwxbase31u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lversion -lwsock32 -lwininet -loleacc -luxtheme
If we do the same command with build=debug instead we get similar commands with just a few differences:
windres --use-temp-file -i../../samples/sample.rc -ogcc_mswud\minimal_sample_rc.o --define __WXMSW__ --define _UNICODE --include-dir .\..\..\lib\gcc_lib\mswud --include-dir ./../../include --include-dir . --include-dir ./../../samples --define NOPCH
g++ -c -o gcc_mswud\minimal_minimal.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -I.\..\..\lib\gcc_lib\mswud -I.\..\..\include -W -Wall -I. -I.\..\..\samples -DNOPCH -Wno-ctor-dtor-privacy -MTgcc_mswud\minimal_minimal.o -MFgcc_mswud\minimal_minimal.o.d -MD -MP minimal.cpp
g++ -o gcc_mswud\minimal.exe #gcc_mswud\minimal.exe.rsp -g -mthreads -L.\..\..\lib\gcc_lib -Wl,--subsystem,windows -mwindows -lwxmsw31ud_core -lwxbase31ud -lwxtiffd -lwxjpegd -lwxpngd -lwxzlibd -lwxregexud -lwxexpatd -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lversion -lwsock32 -lwininet -loleacc -luxtheme
To build the sample with eclipse, we want to make it execute roughly the same commands accounting for the slight differences between the debug and release configuratins. Select File->New->C/C++ project->C++ Managed Build. Enter a project name, select MinGW GCC, make sure the project type is Executable/Empty project, and click the finish button.
Now add a file to the project. You can either
Selecting File->New->Source File, enter a name for the file such as "minimal.cpp" or whatever you want to call it, and hit finish. The new file will automatically open in eclipse. Select and delete the entire contents. In a text editor, open the file WXWIN\samples\minimal\minimal.cpp, select and copy the entire contents, paste into the file just created in eclipse, and save the file.
File->Import->General->File System. Click the next button. Then select the \samples\minimal for the directory. Then select the file minimal.cpp from the list of files this brings up. Finally hit the finish button.
Either way, there should now be a file named minimal.cpp in the project. To build this file, several settings need to be changed. From the menu, select Project->Properties->C/C++ Build->Settings
For GCC C++ Compiler:
For Preprocessor,
for all configurations add __WXMSW__, _UNICODE, HAVE_W32API_H, and NOPCH.
for the release configuration add NDEBUG
For Includes
for all configurations, add ${WXWIN}\include
for the debug configuration, add ${WXWIN}\lib\gcc_lib\mswud
for the release configuration add ${WXWIN}\lib\gcc_lib\mswu
For Optimization
for the release configuration select Optimize more (-O2)
For Debugging
for the debug configuration select Debug level Default (-g)
For Miscellaneous
for all configurations, add -mthreads -W -Wno-ctor-dtor-privacy at the end of the "Other flags" box.
For MinGW C++ Linker:
For Libraries,
for the debug configuration:
for Libraries, add
wxmsw31ud_core, wxbase31ud, wxtiffd, wxjpegd, wxpngd, wxzlibd, wxregexud, and wxexpatd
for the release configuration:
for Libraries, add all of the following: wxmsw31u_core, wxbase31u, wxtiff, wxjpeg, wxpng, wxzlib, wxregexu, and wxexpat
for all configurations
for Libraries, add all of the following: kernel32, user32, gdi32, comdlg32, winspool, winmm, shell32, shlwapi, comctl32, ole32, oleaut32, uuid, rpcrt4, advapi32, version, wsock32, wininet, oleacc, and uxtheme.
for Library search path, add ${WXWIN}\lib\gcc_lib
note: with MinGW the order of libraries is sometimes important and the libraries with names starting with "wx" used with the debug and release configurations should be listed first. You can use the up and down arrows to rearrange the order if necessary.
For Miscelanious,
for all configurations
for liker flags, add -mthreads -mwindows
for Other options (-Xlinker), add --subsystem=windows.
for the debug configuration,
for liker flags, add -g to the existing contents.
Both the debug and release configurations will now build, but the application isn't complete quite yet. The first thing done building the minimal application in the command prompt was
windres --use-temp-file ...
According to this link, eclipse just doesn't support building resource files, so we need to handle this manually.
Copy the files WXWIN\samples\sample.rc and WXWIN\samples\sample.ico into the project folder. (The project folder is the folder containing the minimal.cpp file created earlier). Alternately, you can use File->Import-> ... to import the files into the project.
Now go back Project->Properties->C/C++ Build->Settings->Build Steps.
For Pre-build steps
for the debug configuration, enter windres --use-temp-file -i"${ProjDirPath}/sample.rc" -o"${CWD}\minimal_sample_rc.o" --define __WXMSW__ --define _UNICODE --include-dir ${WXWIN}\lib\gcc_lib\mswud --include-dir ${WXWIN}\include --define NOPCH
for the release configuration enter windres --use-temp-file -i"${ProjDirPath}\sample.rc" -o${CWD}\minimal_sample_rc.o --define __WXMSW__ --define NDEBUG --define _UNICODE --include-dir ${WXWIN}\lib\gcc_lib\mswu --include-dir ${WXWIN}\include --define NOPCH
Next switch back to the Tool Settings tab:
For MinGW C++ Linker:
For Miscellaneous,
for all configurations
for Other objects, add ${CWD}\minimal_sample_rc.o
These 2 extra steps will make eclipse compile the resource file and link the resources into the final executable.
So you start with a brand new project for C++.
Then you add the source code for minimal sample there.
Next you open the project properties you open "C++ Build" -> "Settings" and under "C++ Compiler"->"Directories", you add all your include directories.
Then you go to "C++ Linker"->"Libraries" and add the libraries and a path to them.
Let us know if you still have problems?
Very helpful! Also works for the DLL version with library path ${WXWIN}\lib\gcc_dll instead of ${WXWIN}\lib\gcc_lib .
For a standalone executable, one might extract required DLLs from the vxWidgets library. A minimum post-build step for this is ...
DEBUG:
cmd.exe /Cfor %i in (wxmsw313ud_core wxbase313ud) do xcopy /D /Y "${WXWIN}\lib\gcc_dll\\%i_gcc_custom.dll"
RELEASE:
cmd.exe /Cfor %i in (wxmsw313u_core wxbase313u) do xcopy /D /Y "${WXWIN}\lib\gcc_dll\\%i_gcc_custom.dll"

CMake uses NASM for linking, which fails.

I have an assembler file I want to compile in one run. However, the following code fails:
enable_language(ASM_NASM)
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -f bin")
add_executable(test test.s)
CMake first runs: nasm -f bin -o test.s.o test.s
And then: nasm -f bin -o test test.s.o
The last step fails as test.s.o is already a binary file.
My question is: How do I disable the first compilation step?
There seems to be a bug in nasm module for cmake. Cmake calls nasm for linking which is obviously wrong (that is why you see two calls to nasm). Hotfix is to set
set(CMAKE_ASM_NASM_LINK_EXECUTABLE "ld <FLAGS> <CMAKE_ASM_NASM_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
I hope you solved your problem, however I feel like I need to post here my solution just because that's the only mention of this problem and it doesn't seem to be solved by the only given answer.
Indeed, nasm can compile sources directly to .bin format (and that's really helpful for boot sectors). The problem is that Cmake doesn't seem to support single stage compilation and linking and it tries to link resulting .bin file, which is imposseible, so the execution fails no matter which linker we try to use.
The only solution that came to my mind was replacing add_executable(NAME SOURCE) with add_library(NAME OBJECT SOURCE). Object libraris are not linked, so the file produced will be exactly what we are looking for.
And here is the complete solution:
enable_language(ASM_NASM)
set(CMAKE_ASM_NASM_OBJECT_FORMAT bin)
add_compile_options("$<$<COMPILE_LANGUAGE:ASM_NASM>:-f bin>")
add_library(lib OBJECT core/boot/loader.asm)
The tricky part: the generated file will be hidden within cmake output dir. It sould be referenced with $<TARGET_OBJECTS:lib>.
Enjoy!

How do I debug CMakeLists.txt files?

Is there a possibility to debug CMakeLists.txt files (at least listing of variables) except for the message statement?
There is no interactive debugger for CMake, however there are also the flags -Wdev, --debug-output and --trace which might help. Also remember to check the log files CMakeFiles\CMakeOutput.log and CMakeFiles\CMakeError.log which mainly collect outputs of processes called by CMake (for example while checking for presence of a type or header).
Since version 3.7, CMake now officially supports a "server mode" so integration in IDEs is likely to improve in the near future. Initial support exists both in Qt Creator and Visual Studio 2017 RC
You can try using the new CMake Script Debugger provided by the VisualGDB tool. It uses an open-source fork of CMake that supports stepping through CMakeLists.txt files, setting code/data breakpoints, evaluating/changing variables, etc.
There's a detailed step-by-step tutorial on the new debugger here
I like to use variable_watch to "debug" my CMakeLists.txt files. Just set in top of my script:
variable_watch(SOME_MY_VAR)
There are steveire's CMake Daemon Tools. I haven't used them myself, but they claim to offer possibilities for introspection that seem to be pretty close to a debugger.
Edit: They are now called CMake-server and are part of CMake 3.7.
Also, read about the env var VERBOSE: https://cmake.org/cmake/help/latest/envvar/VERBOSE.html
I used it this way:
export VERBOSE=defined
make
and got some more verbosity.
In other cases, edit CMakeLists.txt file to include the following line:
set(CMAKE_VERBOSE_MAKEFILE ON)
(Some post on this is https://bytefreaks.net/programming-2/make-building-with-cmake-verbose ).
Also, there are useful cmake options controlling debug output, see the manpage: https://cmake.org/cmake/help/latest/manual/cmake.1.html

making conditions for linux and windows when linking libraries

Windows VC++ 2008
linux gcc 4.4.3
I have the following problem. When I compile on windows I need the ws2_32 library. However, when I compile on linux, I don't need to link this.
My CMakeLists.txt
INCLUDE_DIRECTORIES($CLIENT_SERVER_SOURCE_DIR/client)
INCLUDE_DIRECTORIES($CLIENT_SERVER_SOURCE_DIR/cltsvr_ults)
# Link the library
LINK_DIRECTORIES($CLIENT_SERVER_DIR/client)
# Add the executable
ADD_EXECUTABLE(clt test_clt)
# Link the executable to the client library
IF(WIN32)
TARGET_LINK_LIBRARIES(clt client ws2_32)
ENDIF(WIN32)
IF(CMAKE_COMPILER_IS_GNUCXXX)
TARGET_LINK_LIBRARIES(clt client)
ENDIF(CMAKE_COMPILER_IS_GNUCXXX)
I have tried unsuccessfully to compile under linux. Using the above conditions. However, It always tries to link the ws2_32 and I get a compile error. I think that the conditions aren't working, as it always falls through the WIN32 condition.
many thanks for any suggestions,
Since the WIN32 thing is such a fundamental part of CMake, I'd guess that there is more to this than what you mention.
Are you doing a clean check out of your code, or just copying up a whole directory on Linux? If you have all your CMake build files cached from the Windows build, maybe (just maybe!) something has snuck in there and "detects" itself as WIN32 on Linux?
Are you sure it is that line and not something else that causes the link to the stray Win-library? Maybe try a MESSAGE(STATUS "I am here")line within the IF(WIN32) just to make sure.
Are you sure the error is caused by linking that library? I can see a typo in your script, it should be IF(CMAKE_COMPILER_IS_GNUCXX) - you have an extra X on there. Perhaps you are not linking in what you thing you are, and that is why it fails.