I use a wrapper around make to compile C++ code within a project.
For example, the project Foo is laid out as follows:
Foo/
Foo/src/...
Foo/lib_1/..
Foo/lib_2/...
etc
where lib_1, lib_2 are library dependencies of Foo. The src directory has a single
make file which I run on the command line.
Is there a way to teach emacs to always run that file when I do M-x compile? And understand how
to jump to an error in some other file buffer (or open a new buffer for a file) depending on
what the error is on running make (g++) ?
Edit: I guess what I am asking for is project support and support within the project to run a specific custom make file, where errors point to files within the project that emacs can navigate to.
See the variable compile-command. This is what M-x compile defaults to, so you can set it to run the makefile you want. E.g.
cd /your/root/dir ; make
Also see the command recompile if you don't want to always press enter. It's also worth it to bind it to some key.
Related
I am running CoqIDE to use read the textbook series "Software Foundations", I am currently reading the volume "Logical Foundations". I just started Chapter 2 (Induction), but when I try to run the line
From LF Require Import Basics.
I get an error statement
The file ...\LF\Basics.vo contains library
Basics and not library LF.Basics
I tried renaming the directory the file was located in, and recompiled the buffers, but neither of these actions helped. What Shoudl i do in order to solve this problem?
We've been improving the explanation in the soon-to-be-released new version of LF. Here is the relevant bit:
For the [Require Export] to work, Coq needs to be able to
find a compiled version of [Basics.v], called [Basics.vo], in a directory
associated with the prefix [LF]. This file is analogous to the [.class]
files compiled from [.java] source files and the [.o] files compiled from
[.c] files.
First create a file named [_CoqProject] containing the following line
(if you obtained the whole volume "Logical Foundations" as a single
archive, a [_CoqProject] should already exist and you can skip this step):
[-Q . LF]
This maps the current directory ("[.]", which contains [Basics.v],
[Induction.v], etc.) to the prefix (or "logical directory") "[LF]".
PG and CoqIDE read [_CoqProject] automatically, so they know to where to
look for the file [Basics.vo] corresponding to the library [LF.Basics].
Once [_CoqProject] is thus created, there are various ways to build
[Basics.vo]:
- In Proof General: The compilation can be made to happen automatically
when you submit the [Require] line above to PG, by setting the emacs
variable [coq-compile-before-require] to [t].
- In CoqIDE: Open [Basics.v]; then, in the "Compile" menu, click
on "Compile Buffer".
- From the command line: Generate a [Makefile] using the [coq_makefile]
utility, that comes installed with Coq (if you obtained the whole
volume as a single archive, a [Makefile] should already exist
and you can skip this step):
[coq_makefile -f _CoqProject *.v -o Makefile]
Note: You should rerun that command whenever you add or remove Coq files
to the directory.
Then you can compile [Basics.v] by running [make] with the corresponding
[.vo] file as a target:
[make Basics.vo]
All files in the directory can be compiled by giving no arguments:
[make]
Under the hood, [make] uses the Coq compiler, [coqc]. You can also
run [coqc] directly:
[coqc -Q . LF Basics.v]
But [make] also calculates dependencies between source files to compile
them in the right order, so [make] should generally be prefered over
explicit [coqc].
If you have trouble (e.g., if you get complaints about missing
identifiers later in the file), it may be because the "load path"
for Coq is not set up correctly. The [Print LoadPath.] command
may be helpful in sorting out such issues.
In particular, if you see a message like
[Compiled library Foo makes inconsistent assumptions over
library Bar]
check whether you have multiple installations of Coq on your machine.
It may be that commands (like [coqc]) that you execute in a terminal
window are getting a different version of Coq than commands executed by
Proof General or CoqIDE.
- Another common reason is that the library [Bar] was modified and
recompiled without also recompiling [Foo] which depends on it. Recompile
[Foo], or everything if too many files are affected. (Using the third
solution above: [make clean; make].)
One more tip for CoqIDE users: If you see messages like [Error:
Unable to locate library Basics], a likely reason is
inconsistencies between compiling things _within CoqIDE_ vs _using
[coqc] from the command line_. This typically happens when there
are two incompatible versions of [coqc] installed on your
system (one associated with CoqIDE, and one associated with [coqc]
from the terminal). The workaround for this situation is
compiling using CoqIDE only (i.e. choosing "make" from the menu),
and avoiding using [coqc] directly at all. *)
When using EDTS erlang emacs IDE, it doesn't seem to me that there is much integration with rebar, so I am wondering how to specify compile options so that I can add debug_info and {parse_transform, lager_transform}.
EDTS kinda works on .beams, and with this it should be able to compile with exactly the same options. Let me explain.
EDTS works with notion of project (it's accualy xref server, lets assume that those are more or less the same). When you open one source file, he adds it to the "project list", and than he adds all other modules he can find. What is important here, is fact that he is doing it based on .beam files. It have two major significance.
First, if you modules aren't compiled he will think that you make calls to undefined functions (with exception of files that you actually opened in your editor, of course).
Second is fact, that if he can find once compiled binary, he can read and reuse compile flags from it. Of course all new files created in emacs won't have .beam with those options, so they will be compiled with default ones.
So, if you have any issues with the way your files are compiled/modules you can reference just recompile them from command line
$ ./rebar clean compile
and reinitialize EDTS with M-x edts-project-node-refresh or M-x edts-project-node-init
It seems like Project.ede only accepts predefined project, which are Arduino Sketch, Android, Automake and Make. I pasted ede-cpp-root-project, but upon entering project root that has Project.ede, I encountered this error:
eieio-persistent-read: Corrupt object on disk: Unknown saved object
Here is the ede-cpp-root-project I pasted into:
(ede-cpp-root-project "Coloring"
:file "~/workspace/discrete_optimization/hw2/Project.ede"
:include-path '("/"
"/include"
"/include2"
"/include3"))
I really want to create a file per project, not in a centralized file.
Use of a Project.ede file is only for a specific project type of Make or Automake. While you could type it in by hand, you should use ede-new for creating them. Also, only use that type of project if you want EDE to create your Makefiles for you. You are getting the the 'corrupt' message because Emacs will refuse to load the file if it finds anything other than one of the two support project types.
If you would like to use ede-cpp-root-project, you can create any old file like "myproject.el" and put your ede-cpp-root-project config in it. Then do
M-x load-file RET /path/to/myproject.el
to load it up when needed.
I want to run my working pydev project python code by double clicking the main module (outside of eclipse): xxx.py
The problem is that due to my imports being in different packages:
from src.apackage.amodule import obj
when xxx.py is double clicked it complains it doesn't know where the imports are (even though when I run xxx.py in pydev it magically knows what I'm importing).
A simple workaround is to remove all of the packages and move all of the modules into one directory (that obviously works but is very inconvenient)
How can I run my code in the file system without doing that work around?
This page answers my question excellently:
http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/
Bottom line is always execute your code from the top, highest level, root directory (e.g. using a minimal main.py file that executes the main script of your program). Then, use absolute imports always and you never have a missing module issue since you start the program from the top directory and all imports are based off that 'home' path.
The problem you encountered is the natural behavior of most languages. A programm only knows about its working path (the path it is started in), the paths which are registered in the environment variables and at least relative paths.
The "magic" of the executable you created is therefore: It collects all scripts/modules needed, and copies/combines them next to/in the executable. The Executable then runs within the directory where all other scripts also reside and voila ...
If you are not happy with your workaround of creating an executable every time you want to run your project without PyDev there are two alternatives.
First but not the one I would suggest is registering the working path into in the environment variables.
Second and the one I think is much better: Create a link to the python executable and alter the calling string of the textfield "Target:". Append the path to your script you would like to run. Then alter the textfield "Start in:" and enter the project directory. After you did this you should be able to start your project with a simple double click.
(If you rely on external libraries which are neither on the path nor in you project you could search for appending paths temporarily to the pythonpath via the sys module.)
I hope I could help a bit.
I have a project that uses autotools. A nice feature of autotools is 'out-of-source' builds, wheras instead of doing :
cd foobar
./configure
make
I actually create a folder for builds, in which I do the configuration :
cd foobar/builds/linux
../../configure
make
(The nicety is that my source folder is not crippled with the generated Makefiles, and it helps when cross-compiling).
So when I am working on my code in emacs, to run the compilation I'll do M-x compile specifying the compile command as cd ~/foobar/builds/linux ; make .
This works fine until a compilation error occurs. The compilation buffer will list the files with ugly path (like ../../../../src...), which points to a source file, relative to the build folder.However, it seems like emacs does not stay in the build folder at the end of the compile, so the link does not point to anything. Hence, I cannot easily browse back to the error.
I tried playing with compilation-search-path, whithout luck.
Is there a way to force emacs to 'stay' in the compilation folder (so that the paths in the compilation buffer reference existing files ?)
Thanks
PH
If you instead use make -C ~/foobar/builds/linux, emacs should be able to track the Entering directory ..., Leaving directory ... messages that make emits and use this to keep proper references to the files.
Using jamessan advice, I could partially fix the issue by :
setting 'compilation-directory to be one of the 'source' folders (builds/linux/current/src/client)
settting 'compilation-command to change to one of those source folders using -C
Not so sure if both are needed or if it is the best way to do things ...
Thanks anyway !