I just switched to CodeLite for C++ development.
I followed the QuickStart guide and created a simple console executable (g++), and when setting up a new project, you can choose the Build System, which offers the options
Default
CMake
GNU makefile onestep build
NMakefile for MSVC toolset
If I choose "CMake", and leave everything else the way it is, I get my usual hello world code in main.cpp.
Now I want to build it. I execute CMake, which produces a makefile, and then execute "Build" (by pressing F7 or via the menu). That does not work:
C:\Windows\system32\cmd.exe /C cd "\\"C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug"\ProjectName" && C:/mingw/mingw64/bin/mingw32-make.exe -j4 SHELL=cmd.exe -e
"\\C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName"
CMD unterst_tzt keine UNC-Pfade als aktuelles Verzeichnis.
====0 errors, 0 warnings====
The last line says it does not support UNC paths. Not sure whether that's the problem, but anyway, nothing actually gets built.
However, if I simply open a command line in the cmake-build-Debug\ProjectName\ directory, I can execute "make" and my executable is built properly.
Now my question is: Why does CodeLite not build my project? This does not seem to work as intended. I did not change any settings and my project is a clean default, but yet, I have to build it manually.
If I simply choose "Default" instead of "CMake", it gets build, by the way.
A path in UNC (universal naming convention) has \\ before the host name and then the drive, directory, ... letters.
The path "\\C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName" does not look like a proper (UNC or other) path. Was it written this way by the CodeLite build system or did you need to do this manuully?
The form "C:\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName" (or "C:\Windows\Users\ ...") should work on your system.
Related
The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).
I am trying to create generally-accessible compile & run instructions for my CLion project, but can't find the exact terminal command it uses to execute the program (it's makefile, I would assume). From the project directory in the terminal, how would I do this?
The directory looks like this:
I will add a little bit to #Stanley F.'s excellent answer.
FROM the root of the CLion project, this is what works for me. I generally run with a debug profile. The same can be reproduced for release.
When cmake loads its project, it runs
cmake -Bcmake-debug-build -H. ${CMakeOptions}
where CMakeOptions is stored in CLion at
CLion->settings->Build,Execution, Deployment->CMake->[profile]->CMake Options
My general cmake build option is
-DCMAKE_BUILD_TYPE=debug -DSYTEM_ARCH=Linux-gcc5.3.0-x86_645 -CMAKE_CXX_STANDARD=14
[Note the lower-case d for 'debug'. If I do not use this, my system will not work. I wish that CLion did not default to 'Debug']
So, to reproduce what CLion creates upon project reload, I run
rm -rf cmake-debug-build
cmake -Bcmake-debug-build -H. -DCMAKE_BUILD_TYPE=debug -DSYTEM_ARCH=Linux-gcc5.3.0-x86_645 -CMAKE_CXX_STANDARD=14
Then, to build the project, I run
cmake --build cmake-build-debug --target all
Please note that when I run the first cmake command (from CLion or the command line), cmake pulls in lots of libraries from other "precedent" projects as part of the processing of my CMakeLists.txt file. If anything in one of those precedent projects changes, I will not pull them in anew, unless I physically delete the entire cmake-build-debug/ directory. None of CLion's reset tool menu items from my experience will delete that file.
If I am running these commands from the CLion menus, then I have to physically delete the cmake-build-debug/ directory as well (if I have a change in one of the external libraries that I want to pull in).
CLion currently only supports CMake projects. So you have to invoke the CMake executable with the appropriate parameters for your project.
At first, you can delete the cmake-build-debug folder, since this is auto-generated by CLion, which itself invokes CMake. It only contains temporary files.
So your build environment basically contains the 3DTable.c, 3DTable.h and CMakeLists.txt files. At least this is what I get from the screenshot.
To build the project from command line, first navigate to the source directory. Then invoke CMake:
cd <source path of Project_1>
cmake -Bbuild -H.
cmake --build build --target all
Notes:
build is the directory, where CMake will generate temporary files and the build artifacts.
The -H. option tells CMake, where the CMakeLists.txt file is located, which in this case is the current working directory.
The library / executable for your project will be located within the build directory
CLion can tell you, you don't need to hunt.
CMake command line
Select tools\cmake\reload cmake project.
The command line is shown in the CMake window.
Build command line
Select build\build project.
The command line is shown in the messages window.
Example
Mine look like this:
"C:\Program Files\JetBrains\CLion 2021.2.2\bin\cmake\win\bin\cmake.exe" -DCMAKE_BUILD_TYPE=Debug "-DCMAKE_MAKE_PROGRAM=C:/Program Files/JetBrains/CLion 2021.2.2/bin/ninja/win/ninja.exe" -G Ninja -S C:\some_application -B C:\some_application\cmake-build-debug
...
"C:\Program Files\JetBrains\CLion 2021.2.2\bin\cmake\win\bin\cmake.exe" --build C:\some_application\cmake-build-debug --target all -j 9
Reminder
If using Visual Studio you still to specify which environment you are using. Typically this involves using the VS command prompt or executing one of the premade scripts to set up the environment variables. See here.
I have a Qt project file (.pro) and a Makefile (self-written).
The project file is simply used for editing the source files in the IDE:
/home/project/
./src/fooApp.pro
TEMPLATE=app
CONFIG-=qt
TARGET=fooApp
SOURCES+=...
HEADERS+=...
./src/main.c
./src/foo.c
./src/foo.h
./build/Makefile
I would like to build the project via IDE QT Creator 3.5.1
Therefore I would like to invoke make on the Makefile.
During the build process I always get the error that no Makefile can be found hence no build was triggered.
The solution is to always invoke qmake first, then make (even if a Makefile is still present and custom setting make -C ../build in /home/project/)
Could someone please explain, why it is not possible ignore qmake and directly invoke make on the already existing Makefile?
(No Qt library is used for the project)
Regards
This is quite easy, I use makefile only project alot because I like qt-creator as an IDE. In the IDE goto the projects tab on the left.
Select the "build" tab near the top of that page, looks like: (build | run).
In the build steps:
remove the qmake build step by press hovering the mouse over that step and clicking the X that appears.
Edit the build directory so that it is the same directory as your makefile.
Note: you will have to click the shadow build check box next to it to enable it.
remove any other steps you don't want (infact just remove them all for now).
Add a new step make step. It will try to use the default make, but you can override that if you want. Also add any arguments like debug or -j4 etc...
Then you are done :)
Next time you hit build it will simply invoke that make command.
Note: You will need to do the same for any other configurations you have (like release, debug, etc...). You can also just add loads more configurations for doing other make options (if you have them) for instance make doxygen or such...
Just remembered you can also either:
I am not sure why, but when I tested it (as OP did) you can't seem to just setup a make step with parameters -C ../, it seems to want to look in the "build directory" first.
I tend to use the build location since its a nice feature of the IDE.
Note an issue with newer versions of Qtcreator as a makefile IDE is that you cant share your build settings with other people (i.e. can't configure control them) because they are locked to your PC profile... long story... but its very sad and I no longer use qt creator for that one reason.
I am trying to find out if there is a possibility to sign executables produced by the Go compiler. I cannot see this in the build/compile options. Is this even possible?
Signing an executable is not the responsibility of the compiler, but it is part of the build process. Change your build script to run signtool.exe after the Go compiler has generated your EXE or DLL file. Provide the path and password to the private key file (if using a .pfx file) and it will sign it for you. This is the same process that Visual Studio uses.
https://learn.microsoft.com/en-us/windows/desktop/seccrypto/signtool
Apparently Go's go build command is surprisingly spartan: you cannot add additional build steps nor custom commands to go build, nor is there any "hooks" feature for the go command either (other than go generate, but that's a pre-build step when we want a post-build step).
...which means you'll need a makefile.
You'll need make as well, which you'll need to install somehow as it isn't a Windows thing:
Via Chocolatey: choco install make
Or via installing WSL
Or you figure out how to get these binaries from 2006 to work.
Or you could use nmake, which comes with Visual Studio, but has its own dialect for makefiles, which I'm not familiar with.
Another alternative is to consider CMake.
CMake has support for go build, but CMake is more of a "make-make" so it's outside the scope of my answer.
Here's a quick-and-dirty makefile (for GNU make on Windows) for a single-file project main.go, which should (it's untested) automatically runs signtool after a build:
# golang makefile based on https://golangdocs.com/makefiles-golang
BINARY_NAME=mygoproject.exe
build:
go build -o ${BINARY_NAME} main.go
# This runs signtool with a cert in your profile store instead of a *.pfx file, to avoid needing to store a password in the makefile or environment variable: https://stackoverflow.com/questions/26998439/signtool-with-certificate-stored-in-local-computer
signtool sign /sm /s My /n <certificateSubjectName> /t http://timestamp.digicert.com ${BINARY_NAME}
run:
go build -o ${BINARY_NAME} main.go
./${BINARY_NAME}
clean:
go clean
rm ${BINARY_NAME}
Just run make build from your terminal and it should just work (I hope!)
I normally use Qt creator with cmake to program C++ projects. Lately I read quite a bit about meson and it's simplicity and I like to test it. This example explains how to setup meson.
When using meson, I like however to still use Qt creators shortcuts for building (ctrl + B) or running (ctrl + R). How can I configure Qt creator to build a meson project, when I'm using a "generic project"?
Meson is currently not directly supported by Qt Creator. There is a bug report requesting that: https://bugreports.qt.io/browse/QTCREATORBUG-18117 and I am considering to actually implement that.
For the time being I use meson via the "Generic Project". Go to "New File or Project", "Import Project" and there "Import Existing Project". That gets you a dialog where you can select the files that your project consists of.
After that is done you will need to edit "projectname.includes" and add the include directories (one per line) into that file. Then you need to edit "projectname.config" and add defines (one per line) there.
Finally you will need to edit the build configuration and call ninja instead of make there.
With that it works reasonably well for my small project.
Until the QtCreator supports directly meson.build project files, I find this python2 script useful to create QtCreator generic project files: https://github.com/mbitsnbites/meson2ide
with meson and ninja in your PATH, this should work:
$ meson builddir
$ python2 meson2ide.py builddir
this generates a .creator project file in builddir (if you get an error about "mesonintrospect" not found, try this PR: https://github.com/mbitsnbites/meson2ide/pull/1)
To make CTRL+B work properly, In QtCreator build settings, remove the make build step and add a custom build step with the path to the ninja executable, and add the command line arguments
3>&1 1>&2 2>&3
Those redirect allow QtCreator to capture build errors in the "issue" panel.