This is my first time with scons and compiling in general.
This application had a problem which was fixed by this guy here. Now I want to apply that fix manually but only recompile that specific bit of code. So:
followed the instructions and downloaded everything locally.
modified the 3 files accordingly
attempted to recompile:
cd titanium_desktop/modules/ti.Network
scons
scons: *** No SConstruct file found.
File "C:\Python25\Scripts\..\Lib\site-packages\scons-1.2.0\
SCons\Script\Main.py", line 826, in _main
What am I doing wrong and what should I be doing instead?
The SConstruct file is the main SCons build script. Without it, SCons doesnt konw what to do.
I see from your commands that you are trying to do a build of a sub-directory which has a SConscript file, but not a SConstruct file. In this case, you need to tell SCons where the SConstruct file is. The most common way to do this is as follows:
# scons -u
This tells SCons to traverse up the directory hierarchy until it finds the SConstruct file.
You can find more SCons command line options here.
Related
I'm analyzing a CMake project and I want to get all the header files that a source file depends on. Is there a tool or a command like gcc -M or g++ -M to list all the dependencies of one file in the CMake project? It would be better if I could also get which Target each header file belongs to.
Of course I can’t use g++ -M directly because it can’t find some dependencies organized by CMakeLists.txt.
Since the cmake command will generate MakeFile, a tool or command for Make may may also work for me.
Check the build folder for your CMake project. For each target, CMake should generate a file called C.includecache. This file contains the include dependency information.
If, for example, you have a main.c file which is including the stdio.h and math.h headers. The C.includecache file will contain an entry like:
/path/to/main.c
stdio.h
-
math.h
-
I hope this is a simple question and I'm just missing something fundamental.
I'm trying to emulate a binary build manager for an embedded Cortex-M0 target using a CMake project. I'm having some trouble figuring out how to generate list files for each dependency of my executable target.
The current build system, when building a file called main.c passes -Wa,-alh=.\CortexM0\ARM_GCC_493\Debug/main.lst as an argument to gcc. I can't figure out how to get CMake to use the current filename without the extension to save the file.
I've looked at the get_filename_component command, but it appears only to get the filename of the output:
add_executable(TestExe main.c)
get_filename_component(curr_name TestExe NAME_WM)
message(${curr_name})
As expected, this prints TestExe instead of the hoped for main
Is there a simple variable I'm overlooking that I could put in my toolchain file's CMAKE_C_FLAGS like -Wa,-alh=${CURR_SOURCE}.lst? Or some other method that I'm not seeing?
System info:
Windows 10
Msys shell
CMake 3.7.2
arm-none-eabi-gcc v4.9.3
You can use Expansion Rules and extend CMAKE_C_COMPILE_OBJECT:
set(CMAKE_C_COMPILE_OBJECT "${CMAKE_C_COMPILE_OBJECT} -Wa,-alh=<OBJECT>.lst")
But there is unfortunately
no Expansion Rule that does give the current source file without path and extension
so you will get in the above example main.c.o.lst as an output name
Footnote: In CMake generated makefile projects, if you just need the assembly file can just do make main.s or for the pre-processed file make main.i.
I have an OSX 10.7 computer with a non-administrator account, and was attempting to install the pre-compiled versions of gcc and g++ found here. I've attempted to use the answers presented in these questions (three different links) to compile some code with g++, to confusing avail. I have a folder structure like this:
~/code/:
usr/:
local/:
bin/ (3.6MB)
include/ (8.6MB)
lib/ (51MB)
libexec/ (49MB)
share/ (16MB)
c++/:
source/ (contains .cpp files)
g++ -v returns this:
code USER$ usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=usr/local/bin/g++
COLLECT_LTO_WRAPPER=/Users/USERNAME/code/usr/local/bin/../libexec/gcc/ x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC)
An attempt at compiling a file that "#include"s only iostream:
$ usr/local/bin/g++ c++/source/test.cpp -o ex6
In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from c++/source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
I tried compiling with some flags recommended in one of the links mentioned, like this: (with all combinations of "usr/" to "usr/local/include/" and "usr/" to "/usr/local/lib" giving the same result (which is also the same as using no flags).
$ /Users/USERNAME/code/usr/local/bin/g++ source/ex6.cpp -I/Users/USERNAME/code/usr/local/include/ -L/Users/USERNAME/code/usr/local/lib/In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
In short, I'm having trouble understanding what the answers in the links provided are saying to do. I saw reference to a specs file, which I could find no specific information for, and "-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)", for which I couldn't figure out what I was supposed to substitute for "DEFAULT_LIB_INSTALL_PATH".
What should I do to point the downloaded g++ compiler to its own files without placing them in their default location, as I do not have administrative capabilities on this account?
I will provide any information as necessary.
It looks like you don't have required header files. You need to install Command Line Tools from Apple Developers site (free registration needed). The problem is that you don't have administrator account. I suggest that you ask the administrator to install the tools for you. If it is not possible you could try to extract the contents of downloaded package (DevSDK.pkg) to your local directory (Pacifist can do that) and pass the path with the missing headers to your compiler. I haven't tried that though.
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...
Automake 1.14 is causing us a few issues. At first, automake errored with the complaint:
warning: source file 'X' is in a subdirectory but option 'subdir-objects' is disabled
So I enabled subdir-objects, but now it isn't recompiling some files. For example, lets say
src/a/foo.c is compiled in SUBDIR a but in src/b, I would like to compile it again with different preprocessor flags, however since ../a/foo.o already exists, make doesn't rebuild it. This is because subdir-objects changes am_b_OBJECTS to look for ../a/foo.o instead of foo.o. Is there a way I can get around the original complaint and instruct make to build the file a second time with the appropriate preprocessor flags? This all worked on previous versions of automake.
I would settle for executing rm ../a/foo.o before compiling src/b but I don't know how to edit the Makefile.am to make that happen.
This happens if you're using subdir-objects under the same tree from different Makefile.am files. As automake can't see you're using the same source file with different parameters it'll assume it was rebuilt correctly.
The proper solution to this is to not use separate Makefile.am files and instead rephrase the build system as non-recursive automake and so in that case it would then build foo.c as foo-a.o and foo-b.o.