I am learning cedet for my c/c++ projects. However, I am facing difficulty in Make projects.
Say I have a file
main.cpp that looks like this
//main.cpp
#include "temp.h"
blah... <c++ code>
and I have temp.h and temp.cpp
that look like this
//temp.h
some declarations
//temp.cpp
some definitions
Then in emacs+cedet, I do ede-new and then I add a target main using ede-new-target and add main.cpp to main.
Then I write temp.h and temp.cpp and add temp.cpp to target temp.
I choose all targets as program generating this Project.ede file
;; Object Test
;; EDE project file.
(ede-proj-project "Test"
:name "Test"
:file "Project.ede"
:targets (list
(ede-proj-target-makefile-program "main"
:name "main"
:path ""
:source '("main.cpp")
)
(ede-proj-target-makefile-program "temp"
:name "temp"
:path ""
:source '("temp.cpp")
)
)
)
Now when I generate the makefile using ede-proj-regenerate, it creates a Makefile that generates main.o and temp.o
The make however fails as the Makefile generated does not identify the dependency of main.cpp on temp.cpp. How can I tell cedet EDE to identify this dependency? What is wrong in what I am doing here?
And secondly, how do I tell it that I do not want main.o as this is the final target program/executable and not an object file.
For your example, the created Makefile should be creating both main.o, and main. The name of the target you create should be the name of your program, so if you changed the target named "main" to "Pickle", it will create a main.o, and a Pickle program.
When you edit temp.cpp, you should add it to main, or Pickle if you choose to rename the target. Put all your source files for the program into the single target, unless you are choosing to create a library, in which case add temp to a library type target instead.
To "Fix things up", you can use the customize-project command to access all the other options not usually available via simple commands from Emacs proper. That will let you add dependencies on libraries, add your headers as aux src, and other useful things. Just read the doc strings associated with the different options.
A quick start for EDE can be found here.
Related
I'm currently working on an embedded C project in Eclipse, cross-compiling to an M4 Cortex target. This project will create 3 separate executable files: apple.hex, orange.hex, and pear.hex. The "apple" source directory compiles, builds, and links without any dependencies on "orange" or "pear". The "orange" source directory also compiles, builds, and links without any dependencies.
However, "pear" needs to access numerous .h and .c assets from "orange". I've had many attempts at getting my CMakeLists.txt to "find" and "link" the code from "orange" to "pear", but to no avail.
Here is my current CMakeLists.txt file:
cmake_minimum_required(VERSION 3.0)
file(GLOB LD_FILE *gcc_nrf52.ld)
set(MY_APP_DIR ${CMAKE_SOURCE_DIR}/apps/orange)
create_application(
NAME
"pear"
PLATFORM
target
INCLUDE_DIRS
./
${MY_APP_DIR}
LINKER_SCRIPT
${LD_FILE}
SOURCES
${MY_APP_DIR}/foo.c
${MY_APP_DIR}/foo_bar.c
main.c
LIBRARIES
SomeLib_1
SomeLib_2
SomeLib_3
)
However, the compiler keeps complaining, saying that it cannot find "foo.h" and "foo_bar.h".
1) Do I need to separately create a static library in orange in order to access it in pear?
2) If I don't need to create a static library to access orange from pear, how do I link orange to pear?
3) I cannot find where CMake places the object files. Where are they?
This project is all under a single makefile.
Any help would be greatly appreciated, thanks!
I was able to fix my directory issues so that all of the include directories in ${MY_APP_DIR} are being linked into "Pear". However, a new issues has arisen. The linker cannot find the map file needed to create the executable image:
/usr/local/Caskroom/gcc-arm-embedded/5_4-2016q3,20160926/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot open map file /Users/admin/Github/target/apps/pear/pear.map: No such file or directory.
I'm not sure why a map find isn't being created. Is the linker (ld) still missing files?
I'll try to answer your questions
You are not linking your libraries to your target.
You need something like:
$target_link_libraries(yourtarget yourlibraries)
after your add_executable command.
3) I cannot find where CMake places the object files. Where are they?
CMake puts all of its outputs in the build tree by default, so unless you are liberally using ${CMAKE_SOURCE_DIR} or ${CMAKE_CURRENT_SOURCE_DIR} in your cmake files, you should find the output files in the folder where your CMakeLists.txt file is.
The aim is to have small and useful libraries included into a main application.
I create a CMakeLists.txt file to create three different library : image, utils_dir and utils_geom. The thing that bother me is the horrible redundancy with the target definition. So I tried to create some macro and I'm confronted to an inclusion issue.
The pattern of my project is presented below.
src/CMakeLists.txt (main CMakeLists including subdirs)
src/cmake/Macro.cmake (containing macro)
src/libs/core/CMakeLists.txt (library def and macro use)
I can't include my Macro.cmake file which contain the macro definition.
With the following code in the top level CMakeLists.txt (in src/) :
include(Macro.cmake)
test_macro()
And in the Macro.cmake :
macro( test_macro )
MESSAGE("Success !")
endmacro
I've got :
CMake Error at libs/core/CMakeLists.txt:8 (include):
include could not find load file:
Macro.cmake
CMake Error at libs/core/CMakeLists.txt:9 (test_macro):
Unknown CMake command "test_macro".
Did someone is using a likely configuration ?
I am new to Ocaml and just setting up my dev environment with emacs, merlin and flycheck. Everything works more or less expected except one thing : merlin doesn't seem to be able recognise the dependencies between the modules in the same project.
e.g. I have a test project with two modules: main.ml and awesome.ml.
here is my main.ml which references the second module awesome.ml
(* main.ml *)
open Core
module A = Awesome
let _ =
Printf.printf "hello \n Converted to string we get: %s\n"
(A.str_of_t (A.succ A.one_t));
here is awesome.ml:
(* awesome.ml *)
type t = int
let one_t = 1
let succ i = i + 1
let str_of_t = string_of_int
when I send main.ml buffer to evaluate into utop with utop-eval-buffer function, I am getting an error: "Error: Unbound module Awesome"
I have .merlin in the root of the project which has S instruction.
I know it is found by merlin as it doesn't complain about "open Core"
S src
PKG core lwt ounit
B _build/src
B +threads
here is my _tags:
<src/**>: include
<src/**>: package(oUnit), package(core)
true:thread
the regular project compilation with ocamlbuild works fine, no errors.
here is Makefile
## Makefile
default: main
main: main.native
test: test.native
%.native:
ocamlbuild -use-ocamlfind $#
mv $# $*
.PHONY: test default
any ideas why Awesome module is not recognised in utop or this is expected behaviour?
Merlin will see other modules once you have compiled them (in fact, once you have compiled its interfaces). So given your .merlin is correct it will see everything after you run compilation. Your files should indeed be in a src folder, i.e., your project layout, based on your .merlin file should look like this:
Makefile
.merlin
src/
awesome.ml
main.ml
This is not a required layout, but this is the one, that you described to Merlin. The reason, why I suspect that it is not the same, is your Makefile.
P.S. Just as a side note, there is a small issue in your code: you should open Core.Std not Core.
As Ivan's answer pointed out, Merlin can only recognize a module in your project after you compile it. If Merlin is giving you an unbound module Foo error, one solution is to run
ocamlbuild foo.cmi
I had the same problem. I tried installing merlin through opam or sources, but I couldn't solve this problem until I put the ".merlin" file in to the \src directory--not at the root-- with a "REC" tag in it.
I'm working on adding some functionality to the storage manager module in Postgresql.
I have added few source files already to the smgr folder, and I was able to have the Make system includes them by adding their names to the OBJS list in the Makefile inside the smgr folder. (i.e. When I add A.c, I would add A.o to the OBJS list).
That was working fine. Now I'm trying to add a new file hdfs_test.c to the project. The problem with this file is that it requires some extra directives in its compilation command (-I and -L directives).
The gcc command is:
gcc hdfs_test.c -I/HDFS_HOME/hdfs/src/c++/libhdfs -I/usr/lib/jvm/default-java/include -L/HDFS_HOME/hdfs/src/c++/libhdfs -L/HDFS_HOME/build/c++/Linux-i386-32/lib -L/usr/lib/jvm/default-java/jre/lib/i386/server -ljvm -lhdfs -o hdfs_test
Therefore, simply adding hdfs_test.o to the OBJS list doesn't work.
I tried editing the Makefile to look like this:
OBJS = md.o smgr.o smgrtype.o A.o B.o hdfs_test.o
MyRule1 : hdfs_test.c
gcc tati.c -c -I/diskless/taljab1/Workspace/HDFS_Append/hdfs/src/c++/libhdfs -I/usr/lib/jvm/default-java/include -L/diskless/taljab1/Workspace/HDFS_Append/hdfs/src/c++/libhdfs -L/diskless/taljab1/Workspace/HDFS_Append/build/c++/Linux-i386-32/lib -L/usr/lib/jvm/default-java/jre/lib/i386/server -ljvm -lhdfs
but it didn't work out, and I kept getting errors message of the Make trying to compile hdfs_test.c without including the directives.
How do I enforce the Make to include my compilation directives for hdfs_test.c ?
Thanks
You don't need to pass -l and -L at compile time, only at link time. At compile time only -I (include path) directives are required to help the compiler find any extra headers.
You should compile your source file to a .o file, same as all the others. Then add the -L and -l directives to the link command line when the linker is invoked to create the postgres executable. That means all you need to edit in src/backend/storage/smgr/Makefile is the OBJS line to add your output object, as you've already done below. Remove your custom rule, it's unnecessary as well as incorrect.
Just add your extra libraries to the $(LIBS) make variable and add your -L paths to $(LDFLAGS) via src/Makefile.global. src/Makefile.global is generated by configure from src/Makefile.global.in so you actually need to modify configure's behavior to add your includes, library paths and libraries. Don't edit configure directly either; edit configure.in and re-generate it with autoconf.
Yes, GNU Autotools is sometimes referred to as autohell for a reason. It's a bit ... interesting ... to work with sometimes, and there can be a lot of indirection involved in doing simple things.
I have different behaviour of compiler, when building project from IDE and from command-line, which I can not explain.
The detailed issue's description is rather big, but it's really simple.
I have a C++ Builder project, which has a PAS-file included (IncludeUnits.pas). This pas-file has several units and inc-files listed. These files are located in separate folders and these folders are listed in library&include paths in project's options.
Folders layout:
C:\Demo\Bin
C:\Demo\Project
C:\Demo\Project\CBuilder5
C:\Demo\Project\Common
C:\Demo\Source
C:\Demo\Source\Common
Bin is output folder, Project/CBuilder5 holds project (bpr-file), Project/Common holds included pas-file (IncludeUnits.pas), Source and Source/Common hold other files (pas&inc). I think that it's pretty usual layout.
C:\Demo\Project\Common\ IncludeUnits.pas :
unit IncludeUnits;
interface
uses
Test;
implementation
end.
C:\Demo\Source\ Test.pas :
unit Test;
interface
{$I Test.inc}
implementation
end.
C:\Demo\Source\Common\ Test.inc :
// this file is empty
If I compile this project from C++ Builder IDE - it will compile fine. C++ Builder IDE doesn't have any additional paths in IDE settings set.
Now, I want to compile it from command-line. First, I issue
bpr2mak.exe MyProject.bpr
command.
This command creates MyProject.mak file, where I can see all paths ("....\Source" and "....\Source\Common" are the paths in question):
...
INCLUDEPATH = $(BCB)\include;$(BCB)\include\vcl;..\Common;..\..\Source;..\..\Source\Common
LIBPATH = $(BCB)\lib\obj;$(BCB)\lib;..\Common;..\..\Source;..\..\Source\Common
...
Now, I run make command:
make.exe -B -f"MyProject.mak"
It gives me the following output:
C:\PROGRA~1\Borland\CBUILD~2\BIN\dcc32 -N2....\Bin -N0....\Bin -$Y+ -$W -$R -v -JPHNE -M -UC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common -D_DEBUG;_RTLDLL;NO_STRICT -OC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common --BCB ..\Common\IncludeUnits.PAS
Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(6) C:\Demo\Source\Test.pas(1) C:\Demo\Source\Test.pas(5) Fatal: File not found: 'Test.inc'
As you can see - all search path is passed to compiler and the file (Test.inc) is all here - in that Source\Common folder. But still compiler can't find it?
Of course, I run both commands from folder with bpr-file. And changing paths to absolute doesn't help.
Copying Test.inc from Source\Common to Source will help. Changing {$I Test.inc} to {$I Common\Test.inc} will also help.
Why? It seems that I'm missing something. Remember: project have no problems with compiling from IDE, Test.inc is found without copying or changing declaration. Did I miss some switch to make or dcc32?
I found the reason: command line for dcc32 misses -I switch, which specifies paths for include files.
For some reason, bpr2mak doesn't respect this option. Fortunately, it allows you to specify alternate template for conversion bpr -> mak. I edited default template and added "-I" option to it, pass new template to bpr2mak - and it worked.