I am making a Netbeans C++ project with an existing GNUmakefile. I went to File -> New Project -> C/C++ with Existing Sources and selected the folder with my current files (including the GNUmakefile).
However, when I run my app, I get the following error.
make: Makefile: No such file or directory
make: *** No rule to make target `Makefile'. Stop.
BUILD FAILED (exit value 2, total time: 67 ms)
I suspect that my Makefile is named "GNUmakefile", which differs from "Makefile." However, I do not want to rename "GNUmakefile," since I am working on this project with others who want to keep it the same.
Is that why Netbeans complains about my GNUmakefile? How can I tell Netbeans to use GNUmakefile instead?
It looks like you must be invoking make as make -f Makefile, so you are explicitly (whether you realize it or not) saying to use a makefile called Makefile. Otherwise, GNU make would happily use GNUmakefile:
$ ls
GNUmakefile
$ cat GNUmakefile
all: ; #echo done
$ make
done
$ make -f Makefile
make: Makefile: No such file or directory
make: *** No rule to make target `Makefile'. Stop.
Note that you only get the error you reported in the last case. So you just need to change how you are invoking GNU make. Alternatively you could symlink Makefile to GNUmakefile:
$ ln -s GNUmakefile Makefile
$ gmake -f Makefile
done
Related
Most of my team uses a .bat file to set paths and then run a build. The .bat file allows selection of multiple different compiler/target platforms, but all use some version of GCC/G++ or similar compiler.
I created an Eclipse project that simply uses the .bat file rather than re-inventing the wheel and tracking down all the paths needed for each build (which I'd need to update if anyone ever updated the .bat file anyway).
This works great for building, and I can even see compiler errors/warnings, but there are some extra errors always present:
Program "gcc" not found in PATH
Program "g++" not found in PATH
I've seen many questions about these and similar errors, but in those case the user couldn't build, and the solution was to install the tools and/or update their PATH or Eclipse environment settings. I don't want to do that; all the tools I need are installed, and the .bat file works just fine to set the PATH for building. Is there a way to suppress these errors, or have Eclipse not try to find the compiler executable, since the build succeeds anyway?
Edit: As suggested in the answer I've received so far, here is output on the console after putting a full path to a compiler in the global discovery settings, which isn't exactly my favorite solution even if it worked, but I'll probably deal with it. Regardless the errors don't go away:
15:27:24 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"C:\\redacted\\localapps\\MinGW5\\bin\\g++.exe" -E -P -v -dD C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Reading specs from C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
C:/redacted/localapps/MinGW5/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -P -iprefix C:\redacted\localapps\MinGW5\bin\../lib/gcc/mingw32/3.4.2/ C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -dD
ignoring nonexistent directory "C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
#define __cplusplus 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2"
#define __STDC_HOSTED__ 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/mingw32"
#define __GNUC__ 3
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/backward"
...
And then a bunch of #defines
The command string I used in the discovery options for this output was C:\redacted\localapps\MinGW5\bin\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}".
Based on the information provided, these errors are coming from the scanner discovery part of CDT.
On my machine the full error looks like this:
Description Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Program "gcc" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Or as a screenshot
What is going on here is Eclipse CDT is (attempting to) launch GCC and G++ to find out what the global settings are for things like include paths, etc.
To fix the problem, go to the Location specified in the error message and adjust the scanner settings. Here is the matching setting to go with the specific error I received.
Your error might be in the project or in the global settings.
To update the MinGW setting, you can provide the path to a batch file that looks like GCC/G++ but sets up your environment correctly first, or you can point directly at the GCC that Eclipse CDT did not find on its own.
For example you can have:
D:\path\to\my\compilers\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}"
As the setting instead of the default.
To aid the debugging, check the Allocate console in the Console View to see exactly what is being run and what output is being generated.
And here is what you might see when it does not work. Hopefully the error messages in the console are sufficient to resolve the problem on your machine.
21:12:54 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"D:\\path\\to\\my\\compilers\\g++.exe" -E -P -v -dD C:/Temp/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "D:\path\to\my\compilers\g++.exe": Launching failed
Error: Program "D:\path\to\my\compilers\g++.exe" not found in PATH
PATH=[\bin;\bin; -- snip --]
21:12:54 Build Finished (took 37ms)
Here is a screenshot to match:
If it does work, you should see lots of #defines and the like showing the global state of your compiler.
When I create a new ROS package using:
$ roscreate-pkg test std_msgs rospy roscpp
and then I proceed to it, typing:
$ make eclipse-project
Everything is OK.
But when I roscd into an existing ROS package and type the above command, it returns :
make: *** No rule to make target `eclipse-project'. Stop.
Is it because the package isn't created by roscreate-pkg?
did you follow the steps here ? Ros Wiki on IDSs
I know the cause for make having no rule is when the rule isn't found in a Makefile.
I was having the same problem with my project and found that it had no Makefile.
Your question gave me the insight to run roscreate-pkg and voilà that folder had a Makefile. The entire contents are:
include $(shell rospack find mk)/cmake.mk
I was able to solve the same problem by having a Makefile in my project with the same content. I did it by copying the Makefile from the dummy project I created via the following commands:
$ roscreate-pkg dummy std_msgs rospy roscpp
$ cp src/dummy/Makefile src/my-package/Makefile
I am trying to make autocompletion using Gtk.SourceView. I added --pkg gtksourceview-3.0 in the makefile. Now when I try to make, it gives fatal error: gtksourceview/gtksource.h: No such file or directory
Valac (or better gcc) search (by default) header files in /usr/include and /usr/local/include/.
Maybe apt-get did not copy these files in /usr/include/.
So:
1.Open gtksourceview-3.0 package (default path of vapi files is /usr/share/vala/vapi or /usr/share/vala-0.20/vapi)
2.Checks [cheader_filename]: if it is something like:
[CCode (cprefix..., cheader_filename = "gtksourceview/gtksource.h")]
then valac tries to use /usr/include/gtksourceview/gtksource.h or /usr/local/include/gtksourceview/gtksource.h
3.Check if /usr/include/gtksourceview contains gtksource.h
4.If not, search your gtksource.h: we suppose that is in /usr/include. Then create a symbolic link:
# ln -sf /usr/include/gtksource.h /usr/include/gtksourceview/gtksource.h
--pkg is only for the vala pass, if you do a C pass you need to do pkg-config manually for gcc
So, basically you have to require gtksourceview in the configure.ac so that they go in the cflags
that did the trick :)
thanks to friendly people on #vala irc channel
This question/answer will eventually serve as complete answer for this question: How can I manipulate/rotate a JPEG image in C++? Since the answers given to that question are only useful if you have already done all of this below.
I followed the guide here: Compiling libjpeg
(The accepted answer guide using MINGW32 Shell)
It doesn't work despite having downloaded a fresh copy:
$ make
make all-am
make[1]: Entering directory `/c/tmp/jpeg-9'
CC jaricom.lo
CC jcapimin.lo
jcapimin.c:127:1: error: conflicting types for 'jpeg_suppress_tables'
jcapimin.c:128:1: note: an argument type that has a default promotion can't matc
h an empty parameter name list declaration
In file included from jcapimin.c:22:0:
jpeglib.h:997:14: note: previous declaration of 'jpeg_suppress_tables' was here
make[1]: *** [jcapimin.lo] Error 1
make[1]: Leaving directory `/c/tmp/jpeg-9'
make: *** [all] Error 2
8d and 9 both do the same.
After making the change noted in this question: Compile libjpeg with mingw
Add the following definition to the jconfig.h
#define HAVE_PROTOTYPES 1
I get this output when making:
$ make
make all-am
make[1]: Entering directory `/c/tmp/jpeg-9'
CC jaricom.lo
In file included from jinclude.h:20:0,
from jaricom.c:17:
jconfig.h:5:24: warning: extra tokens at end of #undef directive [enabled by def
ault]
CC jcapimin.lo
In file included from jinclude.h:20:0,
from jcapimin.c:21:
jconfig.h:5:24: warning: extra tokens at end of #undef directive [enabled by def
ault]
jcapimin.c:127:1: error: conflicting types for 'jpeg_suppress_tables'
jcapimin.c:128:1: note: an argument type that has a default promotion can't matc
h an empty parameter name list declaration
In file included from jcapimin.c:22:0:
jpeglib.h:997:14: note: previous declaration of 'jpeg_suppress_tables' was here
make[1]: *** [jcapimin.lo] Error 1
make[1]: Leaving directory `/c/tmp/jpeg-9'
make: *** [all] Error 2
Then you have to run "autoheader" to fix this and make again.
It supposedly made but there is nothing in my build directory set by ./configure --prefix=/c/tmp/jpeg-9-build/
I found the libjpeg-9.dll in the .lib folder within the project directory.
Messy..Now the question is: How do I use it in Eclipse?
I have the exe's in the main directory, some exe's and the DLL in the .lib sub-directory but no .lib file - How do I go about importing these into an eclipse project so that I can call functions in the DLL?
$ make install gathered the files in the build directory.
I migrated the contents of the build directory into the working Eclipse project and linked the library and include paths:
I'm not sure if this is right for how I want to use it but it's something and it compiles. Next part: Calling functions out of the DLL?
Related to using compiled jpegtran.exe: jpegtran.exe not correctly rotating image
Trying to use libraries and compile in separate project: Need help compiling jpegtran.c code from libjpeg
Current issue: Need help compiling jpegtran.c code from libjpeg
Your advice for updating the jconfig.h file to #define HAVE_PROTOTYPES 1 is only a band-aid solution for a deeper problem: jconfig.h is corrupted and has incorrect #undef for many important items your compiler supports.
The proper way to work around this is to follow the install.txt advice to manually compile ckconfig.c and have it generate a jconfig.h for you, then proceed to make, and make install.
Something like this:
cmake --get-variable=MY_CMAKE_VARIABLE
The variable may exist in an included CMake file.
If you have an existing cache file, you can do:
grep MY_CMAKE_VARIABLE CMakeCache.txt
If you do not yet have a cache file and you want to see what options there are in a CMakeLists.txt file, you can do (in a different directory since this will write a cache file):
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE
which will return to you something like
<VARIABLE>:<TYPE>=<VALUE>
If it is an advanced variable, add the -A flag to the same command and it will include advanced variables. Of course, if you only want the value, you can do:
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE | cut -d "=" -f2
EDIT
For example, with a CMakeLists.txt that is:
cmake_minimum_required(VERSION 2.8)
project(test)
include(otherFile.txt)
set(MY_VAR "Testing" CACHE STRING "")
And where otherFile.txt is:
set(MY_OTHER_VAR "Hi" CACHE STRING "")
The command (run from another directory):
cmake -L ../cmaketest
Gives:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tgallagher/cmaketest-build
-- Cache values
CMAKE_BUILD_TYPE:STRING=
CMAKE_INSTALL_PREFIX:PATH=/usr/local
MY_OTHER_VAR:STRING=Hi
MY_VAR:STRING=Testing
So, it does show variables from other files. It should parse the entire build. The issue though is that it will not show any variables that are not marked with CACHE. And it will not show any that are cached INTERNAL, and will only show ADVANCED if -LA is used instead of -L.
If your variables are marked as INTERNAL or not CACHE'd at all, then there is no method within CMake to pull it out. But, non-CACHE'd variables are meant to be transient, so I'm not sure why you would need them outside of a build environment anyway.
Use:
cmake -LA -N /path/to/project
to get a listing of all cache values. The -N is important; it prevents cmake from trying to generate any build files, and just shows you what's in the cache.
If the variable you want is not something you're setting, but something from the defaults, you can use
cmake --system-information
And grep that. Note it does seem to take a second or two which seems kinda slow.
If for example you're trying to do this to configure your cmake vars in the first place, it avoids getting the cart out in front of the horse. :)
You can also pass this a file name. So you can try only generating it if it doesn't exist, and parse the file if it does (to save that 1-2 seconds).
If you need get non cached user variable but can't edit original cmake script, you may resort to a trick. Create new CMakeLists.txt file in another directory with the following content:
include(<Path to original CMakeLists.txt>)
message(STATUS "MY_VAR={${MY_VAR}}")
It is quite possible, cmake will made a lot of errors while running in new directory. Relative paths, if used in original script, is definitely a cause for such errors. But cmake will print last value assigned for your variable. Further, filter all errors and warnings using any well known text processor (assume UNIX familiar), for example:
cmake . | sed -n 's/-- MY_VAR={\(.*\)}/\1/p' 2>&1
I use this approach in projects maintenance scripts, it is reliably as long as original CMakeLists.txt has no syntax errors.
-D <var>:<type>=<value>:
When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project's default value. The option may be repeated for as many cache entries as desired.