In my CMakeLists.txt file, I use a custom command
add_custom_command(TARGET my_target
POST_BUILD
COMMAND ${CMAKE_COMMAND} ${CMAKE_SOURCE_DIR}
COMMAND make -j`nproc`
WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
because I want to rerun make after building my_target. It shows this warning -- warning: -jN forced in submake: disabling jobserver mode. Everything works fine but how can I remove this warning?
Remove the -j option from your make invocation in your CMake file and the warning will go away. By forcing this option you're essentially creating an entirely new jobserver domain, separate from the already-existing one (so if you ran make -j$(nproc) from the command line, then ran this, you would have $(nproc)*2 jobs running).
Related
I have installed Codelite 15.0.6 and also wxWidgets-3.1.5 from source using procedure on this site. https://docs.codelite.org/build/build_wx_widgets/ When creating project using wxCrafter - wxDialog or any wx[Method] the project can not clean or build.
/usr/bin/make -j16 -e -f Makefile clean
----------Cleaning project:[ C-Simple-Projects - Debug ]----------
make[1]: wx-config: Command not found
make[1]: wx-config: Command not found
rm -f -r ../build-Debug/C-Simple-Projects
=== build completed successfully (0 errors, 0 warnings) ===
I can understand the Compiler & Linker Options setting which calls wx-config --cxxflags is unable to be found, but calling wx-config --cxxflags from the command line works.
sudo make install
which completed successfully and can find wx-config in my shell using terminal.
> % wx-config --cxxflags
-I/usr/local/lib/wx/include/osx_cocoa-unicode-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__
My problem is also that the Language Server shows file not found.
Changed settings for make in the project to "default" and the application started building. Issue is related to Codelite makefile generator setting. I also changed the compiler options to include fully qualified path to wx-config executable. Will try to use Save as Template - see if that will generate other projects with these setting preconfigured. Fingers crossed. actually adding -std=cxx17 to linker options did the trick. resolved!
I need to compile openssl 1.0.1f version with afl-fuzz and then use it in an application to find heartbleed bug. I have done so far;
Go to openssl1.0.1f directory and run following command
./config CC="afl-gcc" CXX="afl-g++"
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
make && make install
Everything works fine but during compilation I see gcc -I commands compiling files rather than afl-gcc and I donot see Instrumentation details at the end as I see it in simple programs I compile with afl-fuzz. I am not sure openssl has compiled with gcc or afl-gcc. I have also replaced gcc with afl-gcc in Makefile but no result.
Can someone please explain as in all blogs about openssl and afl-fuzz, I have found these commands only.
Thanks.
I was making a simple mistake of calling ./configure after manually making changes to Makefile. Each ./configure command overwrites previous Makefile. So my step should be in following order.
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
Manually replace every occurrence of `gcc`to `afl-gcc` in Makefile
make && make install
Thanks.
I'm trying to build XercesC-3.1.2 with MinGW.
After running $ mingw32-make in the xerces directory, I get the following error:
mingw32-make[4]: Entering directory '/my/path/to/xerces-c-3.1.2/src'
process_begin: CreateProcess(NULL, /bin/mkdir -p xercesc/util, ...) failed.
make (e=2): The system cannot find the file specified.
Following the XercesC build instructions, I'm running the configure script as
$ ./configure CC=mingw32-gcc CXX=mingw32-g++
but without the variable LDFLAGS=-no-undefined. This is contrary to the build instructions in the XercesC webpage because otherwise the configure script will not work because the flag is not recognized by gcc. The configure script seems to run fine, however. After that, running mingw32-make gives the error above.
My mingw32-make and mingw32-gcc versions are
mingw32-gcc/g++ 4.8.1
mingw32-make 3.82.90
I tried adding C:\MinGW\libexec\gcc\mingw32\4.8.1 to my PATH, as suggested by Codeblocks, but had no exit.
I also fresh installed MinGW in another machine that has no other compiler (or Cygwin, or anything) and got the same results.
I guess you are using MSYS to run the configure script, so why are you using mingw32-make for the make step? You should run the make step in MSYS too, and use the make which is provided with MSYS. The error message which you see suggests that mingw32-make is unable to resolve the path to /bin/mkdir, which is an MSYS command, and should not be visible outside the MSYS shell process context.
FWIW, xerces-c-3.1.2 builds OOTB for me, cross-compiling with gcc-4.9.3 and binutils-2.24.1, as follows:
tar xf ~/Downloads/xerces-c-3.1.2.tar.xz
mkdir xerces-c-3.1.2/build
cd xerces-c-3.1.2/build
../configure --build=x86_64-linux-gnu --host=mingw32 --prefix=/mingw --enable-static --enable-shared
...
make LDFLAGS=-no-undefined
make prefix=`pwd`/dist/staged install
Is there a way to configure CLion to use a local makefile to compile code, rather than CMake? I can't seem to find the way to do it from the build options.
Update: If you are using CLion 2020.2, then it already supports Makefiles. If you are using an older version, read on.
Even though currently only CMake is supported, you can instruct CMake to call make with your custom Makefile. Edit your CMakeLists.txt adding one of these two commands:
add_custom_target
add_custom_command
When you tell CLion to run your program, it will try to find an executable with the same name of the target in the directory pointed by PROJECT_BINARY_DIR. So as long as your make generates the file where CLion expects, there will be no problem.
Here is a working example:
Tell CLion to pass its $(PROJECT_BINARY_DIR) to make
This is the sample CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.4)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest COMMAND make -C ${mytest_SOURCE_DIR}
CLION_EXE_DIR=${PROJECT_BINARY_DIR})
Tell make to generate the executable in CLion's directory
This is the sample Makefile:
all:
echo Compiling $(CLION_EXE_DIR)/$# ...
g++ mytest.cpp -o $(CLION_EXE_DIR)/mytest
That is all, you may also want to change your program's working directory so it executes as it is when you run make from inside your directory. For this edit: Run -> Edit Configurations ... -> mytest -> Working directory
While this is one of the most voted feature requests, there is one plugin available, by Victor Kropp, that adds support to makefiles:
Makefile support plugin for IntelliJ IDEA
Install
You can install directly from the official repository:
Settings > Plugins > search for makefile > Search in repositories > Install > Restart
Use
There are at least three different ways to run:
Right click on a makefile and select Run
Have the makefile open in the editor, put the cursor over one target (anywhere on the line), hit alt + enter, then select make target
Hit ctrl/cmd + shift + F10 on a target (although this one didn't work for me on a mac).
It opens a pane named Run target with the output.
Newest version has better support literally for any generated Makefiles, through the compiledb
Three steps:
install compiledb
pip install compiledb
run a dry make
compiledb -n make
(do the autogen, configure if needed)
there will be a compile_commands.json file generated
open the project and you will see CLion will load info from the json file.
If you your CLion still try to find CMakeLists.txt and cannot read compile_commands.json, try to remove the entire folder, re-download the source files, and redo step 1,2,3
Orignal post: Working with Makefiles in CLion using Compilation DB
To totally avoid using CMAKE, you can simply:
Build your project as you normally with Make through the terminal.
Change your CLion configurations, go to (in top bar) :
Run -> Edit Configurations -> yourProjectFolder
Change the Executable to the one generated with Make
Change the Working directory to the folder holding your executable (if needed)
Remove the Build task in the Before launch:Activate tool window box
And you're all set! You can now use the debug button after your manual build.
Currently, only CMake is supported by CLion. Others build systems will be added in the future, but currently, you can only use CMake.
An importer tool has been implemented to help you to use CMake.
Edit:
Source : http://blog.jetbrains.com/clion/2014/09/clion-answers-frequently-asked-questions/
I am not very familiar with CMake and could not use Mondkin's solution directly.
Here is what I came up with in my CMakeLists.txt using the latest version of CLion (1.2.4) and MinGW on Windows (I guess you will just need to replace all:
g++ mytest.cpp -o bin/mytest by make if you are not using the same setup):
cmake_minimum_required(VERSION 3.3)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest ALL COMMAND mingw32-make WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
And the custom Makefile is like this (it is located at the root of my project and generates the executable in a bin directory):
all:
g++ mytest.cpp -o bin/mytest
I am able to build the executable and errors in the log window are clickable.
Hints in the IDE are quite limited through, which is a big limitation compared to pure CMake projects...
While making a project with Makefile, I get this error:
error: implicit declaration of function ‘fatal’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
The ./configure --help shows:
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--disable-dependency-tracking speeds up one-time build
--enable-dependency-tracking do not reject slow dependency extractors
--disable-gtktest do not try to compile and run a test GTK+ program
--enable-debug Turn on debugging
How can I tell configure not to include -Werror?
Werror is a GCC argument, and you cannot remove it directly via ./configure. Otherwise, an option like --disable-error would show up in the help text. However, it's possible.
Set an environment variable:
export CFLAGS="-Wno-error"
That's for C compilers. If the project uses C++, do:
export CXXFLAGS="-Wno-error"
In the very rare case the project does not honor this variables, your last resort is to edit the configure.ac file and search for -Werror and remove it from the string it occurs in (be careful though).
It seems like the feature has been in autotools for many years:
./configure --disable-werror
Unfortunately, I wasn't able to get the following specific case to work:
./configure --enable-wno-error=unused-value
Maybe it could work if one escaped the '=' symbol, assuming it's possible. Like skim says, one can still use CFLAGS or CXXFLAGS.
I had to use --disable-Werror (with an uppercase W) on my module. While sudoman's answer above suggests to use --disable-werror (with a lowercase w).
It may look like a typo, but it is actually dependent on your particular configure setup, especially if configure is generated by autoconf. What needs to be passed to the configure script to disable Werror depends on how the build system was setup.
If your project uses the AX_COMPILER_FLAGS option from the autoconf-archive project, then by default -Werror is enabled.
In another module you may find something like this:
+AC_ARG_ENABLE([werror],
+ AC_HELP_STRING([--disable-werror],
+ [do not build with -Werror]),
And thus you would need to use --disable-werror.
This works for me, compiling curlpp on Lubuntu 16.10:
./configure --disable-ewarning
I ran into this problem, and it turned out that GCC was not installed on my freshly-started EC2 instance running Ubuntu 20.04 (Focal Fossa).
Simply running sudo apt install gcc fixed this issue for me.