make: *** No rule to make target `all'. Stop. Eclipse error - windows

I've just downloaded Eclipse CDT developer kit (87MB) for Windows. I've also installed MinGW, and msys.
I also added this to PATH: C:\msys\1.0\bin;C:\mingw\bin. and restarted computer after that. I've checked by type "make --version" in cmd and it works.
However, for some reason I cannot compile my C project. I don't get binary files and got only the following things in COnsole:
**** Build of configuration Default for project XXX ****
make all
make: *** No rule to make target `all'. Stop.
Could some one help me with this please?

For future reference, if you're trying to import an existing project with a makefile...
This message will still pop up if your makefile doesn't have an "all" rule. Using the "Generate Makefiles automatically" option should take care of this automatically. If you don't want makefiles made for you, you have at least 3 simple options...
Option 1
If you don't want to use a rule by that name, use twokats' solution. Here's a clarification.
Go to Project Properties -> C/C++ Build -> Behaviour Tab.
Leave Build (Incremental Build) Checked.
Remove "all" from the text box next to Build (Incremental Build).
This lets Eclipse know you aren't trying to use a make target called "all". For some reason, that is the default.
Option 2
Use something similar to Etiennebr's makefile. Note, the all: $(TARGET) line is the rule that Eclipse is complaining it can't find.
Option 3
Substitute "all" with a rule name of your choice, and be sure to include that rule in your makefile.

Just for your reference, there is a way to configure the CDT build options. I had this same error message (although I did have a make target - just not named "all") and found this solution (for Galileo + CDT):
Right click your project and choose Properties. The Properties dialog will appear and you should see a C/C++ Build option where you can set specific build options. Highlight this item, and the Properties page will appear. Choose the configuration you wish to modify, and then in the section below that you should see 2 tabs: Builder Settings and Behavior. It is the Behavior tab you want. In this section you can set preferences for build settings and workbench settings, including specifying a target name (default is "all") or turning off automatic builds.
This was incredibly helpful to me when I started using the CDT. My source code is separate from the build area, and until I configure, no makefiles exist. When I configured, my default target name is explicitly "default", not "all". It was annoying to have Eclipse report an error in my project before I did anything. Setting up the environment to match my development worked wonders. HTH.

right click the project Properties->C/C++ Build, in the "Builder Settings" check the "Generate Makefiles automatically" option, and then select the "Builder type" option to "Internal builder", and then click ok, the problem was solved!

I spent a lot of time on this error and now realized that those projects that are not compiled were created before I installed MinGW and msys so there was no makefile before. And there was no include folder with link to the makefile. That's the reason why I could not compile it. Now as I create new project, it's fine.
However, I wonder if there is any way to add the path to makefile for the previous projects?
Thanks

You should take a look at your makefile (or create one if missing). That's the default makefile :
CXXFLAGS = -O2 -g -Wall -fmessage-length=0
OBJS = main.cpp
LIBS =
TARGET = main.exe
$(TARGET): $(OBJS)
$(CXX) -o $(TARGET) $(OBJS) $(LIBS)
all: $(TARGET)
clean:
rm -f $(OBJS) $(TARGET)

Related

OMNET++ 5.1 opp_makemake

I installed OMNET++ 5.1 on my Ubuntu 16 OS and imported my project into the Eclipse IDE. But I can not compile my project as before. Make is giving me error:
make1: *** No rule to make target 'msgheaders'. Stop.
I have a folder called loggingWindow that has its own custom makefile and is excluded from the source.
But I noticed that the generated makefile is not correct:
The makefile is calling msgheaders and smheaders targets in the logginWindow folder. The loggingWindow is a completely separate application with its own makefile and has no idea about mshheader!
Also make clean does not work!
The clean window stuck without any progress:
As a temporary workaround, I have added phony targets (msgheaders, smheaders) in order to compile my project.
As a workaround you can add these targets to your own Makefile in logginWindow, for example:
msgheaders:
echo Do nothing
smheaders:
make all
# content from your existing Makefile
all:
...

Is the first target in Makefile an implicit phony target?

I am studying a Makefile obtained from a compiler course project. Only a part of it is pasted here.
# Retain intermediate bitcode files
.PRECIOUS: %.bc
# The default target builds the plugin
plugin:
make -C lib/p1
# create .bc from source
%.bc: %.c
clang -emit-llvm -O0 -c $*.c -o $*.bc
# run printCode on a .bc file
%.printCode: %.bc plugin
opt -load Debug/lib/P1.so -printCode $*.bc
As you see, the target 'plugin' has no dependencies, which, if I understand correctly, should mean that its recipe never runs (unless it is declaared as a phony target, which is not the case here)
However, when I type 'make printCode', (printCode is the last target in the list) the plugin target does execute. How is this made possible? Is there some implicit rule stating that the first target of a Makefile is regarded as a phony target, such as 'all'?
You've got things a little backward.
A rule like the plugin rule can run. You can run it by executing 'make plugin', or 'make' if it's the default target (which it is in this case by virtue of being the first), or if it is a prerequisite of another target that must be built.
I'm not sure exactly what happens when you 'make printCode', since you are showing us only part of the makefile and there is no rule that fits, but judging by this rule:
%.printCode: %.bc plugin
opt -load Debug/lib/P1.so -printCode $*.bc
I'd guess that the printCode rule depends on either plugin or something like foo.printCode that depends on plugin. So Make sees that plugin is a prerequisite, sees that no such file exists, and determines therefore that plugin must be built. It then looks for a rule to build plugin, finds it and runs it.

Using local makefile for CLion instead of CMake

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...

How to convert Makefile into XCode compatible configuration?

I am moving away from simply using a Makefile and text editor. I would like to convert my Makefile so that I can use XCode properly. How can I convert this Makefile?
all:
gcc engine.c $(MRUBY_HOME)/build/host/lib/libmruby.a -I $(MRUBY_HOME)/include $(shell pkg-config --cflags --libs sdl2)
there is nothing stopping you from using a makefile in Xcode. just setup your target as an external build system and populate the "Build Tool" setting with the path to make (/usr/bin/make) and the "Directory" field pointing to the directory in your project containing the makefile. you can populate the "Arguments" field with any arguments needed for your makefile; these can be done with Xcode variables such as $(ACTION) (build, clean) and $(CONFIGURATION) (debug, release).
If you want to do away with the makefile completely then you will need to first add the source files and libraries to your target under the "build phases" tab for your build target. Any shell scripts can be added as a new "run script" build phase. other settings can be set from the "build settings" tab; specifically the "other c flags" field, although most compiler and linker settings should appear as options in that section.

cmake & gcc compiles every file every time

I'm a learning c++ developer writing a game initially on the Mac platform using XCode, but now moving to cross platform by leveraging CMake. So far I can get it compiled on my ickle linux netbook and I'm putting together a dev environment on this machine for on the go coding. However I'm finding that gcc recompiles every file whenever I make a change. Clearly I need some additional configuration to the CMakeLists.txt . My current one is very simple. Like so;
cmake_minimum_required (VERSION 2.8)
set (source
Creature.cpp
DisplayManager.cpp
Engine.cpp
EngineState.cpp
Entity.cpp
GameWorld.cpp
GfxSFML.cpp
Item.cpp
Map.cpp
Position.cpp
Projectile.cpp
ScreenTile.cpp
SquadAI.cpp
Terrain.cpp
UIButton.cpp
UICharPanel.cpp
UIView.cpp
Utility.cpp
Weapon.cpp
fov.cpp
main.cpp
)
find_package (OpenAL)
find_package (OpenGL)
find_package (SFML)
set(CMAKE_CXX_FLAGS "-g -Wall -pg")
add_executable (tractionedge ${source})
target_link_libraries(tractionedge ${SFML_LIBRARY} ${OPENGL_LIBRARY} ${OPENAL_LIBRARY})
I've concentrated so far on C++ as a language rather than build systems by sticking with XCode for everything. My knowledge of Autotools (make?) and Gcc is very limited. How do I have gcc only recompile the changed source?
Are you rerunning cmake every time? If you just modify one source file, you should be able to simply rerun make, and it should rebuild just the one object file before linking. If you rerun cmake, it might mark all of the source files dirty and rebuild everything.
Only rerun cmake if you change the actual list of source files being used, or other major changes like that.
Rebuilding only the modified sources SHOULD be the default behavior. Of course if you change a central header included by nearly all dependent cpp files it'll trigger a nearly complete rebuild. Look at what happens if you only modify one cpp file (adding a comment or alike), if more than that compilation unit is compiling then I propose you to invest more time investigating it eventually giving you my EMail to have a deeper look at the configuration.
Another possibility is that you are compiling under windows and using a 2.8 cmake that has a bug regarding this. Look at a 2.9 version to see if that defect is away then: http://www.mail-archive.com/cmake#cmake.org/msg24876.html
I would rewrite your CMakeLists.txt using glob (maybe move the files in a "src" directory if you have other *.cpp files around) and give your project a name (this sets some important variables):
cmake_minimum_required (VERSION 2.8)
project(TRACTION)
file (GLOB TRACTION_SOURCES *.cpp)
find_package (OpenAL)
find_package (OpenGL)
find_package (SFML)
set(CMAKE_CXX_FLAGS "-g -Wall -pg")
add_executable (tractionedge ${TRACTION_SOURCES})
target_link_libraries(tractionedge ${SFML_LIBRARY} ${OPENGL_LIBRARY} ${OPENAL_LIBRARY})
I also experienced unnecessary rebuilds using cmake and visual studio. The problem is related to an inappropriate x64 configuration parameter: Visual Studio 2008 Unnecessary Project Building
A simple solution in many of these cases is to completely wipe the build tree and regenerate it (and I mean something along the lines of rm -rf build && mkdir build && cd build && cmake -G "Unix Makefiles" ../src, not just make clean)

Resources