I've configured CEDET for emacs following Alex article (great!!).
Now, the questions:
I've generated GTAGS with Gnu Global in my /usr/include, how can i check if semantic is using GTAGS?
Can I keep my GTAGS in another directory and instruct semantic to use that dir?
In C/C++ sources, completion on include statement (from system
headers) doesn't list all available headers. Ok, this is a stupid
problem.. but makes me think something is not working right
You can use the command:
M-x semantic-c-describe-environment RET
to find out about your include path and CPP macro settings.
To test GNU Global use, you can use:
M-x semanticdb-test-gnu-global RET printf RET
to search for "printf" in in some project. Since your project (perhaps in /home/you/myproject) does not have printf in it, it will fail, but if you opened a file in /usr/include, and did the same command, it will hopefully identify printf.
A more general way to ask about GNU Global is with:
M-x cedet-gnu-global-version-check RET
That all said, the GNU Global support is best in situations where you want to have lots and lots of preparsed files that you access infrequently. Once a header is accessed once (like for printf), then the GNU Global database won't be used anymore, because an equivalent Semantic database will have been created for it. This is necessary because GNU Global does not provide enough information to do smart completion.
Related
I am writing a C++ program using gtkmm as the window library and autotools as my build system. In my Makefile.am, I install the icon as follows:
icondir = $(datadir)/icons/hicolor/scalable/apps
icon_DATA = $(top_srcdir)/appname.svg
EDIT: changed from prefix to datadir
This results in appname.svg being copied to $(datadir)/icons/hicolor/scalable/apps when the program is installed. In my C++ code, I would like to access the icon at runtime for a window decoration:
string iconPath = DATADIR + "/icons/hicolor/scalable/apps/appname.svg";
// do stuff with the icon
I am unsure how to go about obtaining DATADIR for this purpose. I could use relative paths, but then moving the binary would break the icon, which seems evident of hackery. I figure that there should be a special way to handle icons separate from general data, since people can install 3rd party icon packs. So, I have two questions:
What is the standard way of installing and using icons with autotools/C++/gtkmm?
Edit: gtkmm has an IconTheme class that is the standard way to use icons in gtkmm. It appears that I add_resource_path() (for which I still need the installation prefix), and then I can use the library to obtain the icon by name.
What is the general method with autotools/C++ to access the autotools installation prefix?
To convey data determined by configure to your source files, the primary methods available are to write them in a header that your sources #include or to define them as macros on the compiler command line. These are handled most conveniently via the AC_DEFINE Autoconf macro. Under some circumstances, you might also consider converting source files to templates for configure to process, but except inasmuch as Autoconf itself uses an internal version of that technique to build config.h (when that is requested), I wouldn't normally recommend it.
HOWEVER, the installation prefix and other installation directories are special cases. They are not finally set until you actually run make. Even if you set them via the configure's command-line options, you can still override that by specifying different values on the make command line. Thus, it is not safe to rely on AC_DEFINE for this particular purpose, and in fact, doing so may not work at all (will not work for prefix itself).
Instead, you should specify the appropriate macro definition in a command-line option that is evaluated at make time. You can do this for all targets being built by setting the AM_CPPFLAGS variable in your Makefile.am files, as demonstrated in another answer. That particular example sets the specified symbol to be a macro that expands to a C string literal containing the prefix. Alternatively, you could consider defining the whole icon directory as a symbol. If you need it only for one target out of several then you might prefer setting the appropriate onetarget_CPPFLAGS variable.
As an aside, do note that $(prefix)/icons/hicolor/scalable/apps is a nonstandard choice for the installation directory for your icon. That will typically resolve to something like /usr/local/icons/hicolor/scalable/apps. The conventional choice would be $(datadir)/icons/hicolor/scalable/apps, which will resolve to something like /usr/local/share/icons/hicolor/scalable/apps.
In your Makefile.am, use the following
AM_CPPFLAGS = -DPREFIX='"$(prefix)"'
See Defining Directories in autoconf's manual.
I have this problem all the time in Linux programming. As long as all the manuals and almost all the source code for Linux are C-centric, all references to some function needs only some include <something.h> line and the function is accessible from the C/C++ code.
But I am programming in assembly language and know almost nothing about C/C++.
In order to be able to call some function, I have to import it from the corresponding .so library.
How to determine the file name of the library? It often differs from the name of the library itself and is not specified in the manuals.
For example, the name of the XLib is actually libX11.so.6. The name of the XShm extension library seems to be libXext.so.6.
Is there easy way to determine the secret real name of the library, using provided C manuals and references?
This is another not-100%-accurate method that may give you some ideas as to how you can narrow things down a bit. It doesn't exactly fit the question because it uses common linux utilities instead of man files, but it may still be helpful.
Use your distribution's package management software.
For example, on Arch Linux, if you were interested in a function in GLFW/glfw3.h, you could find out who owns that file:
$ pacman -Qo /usr/include/GLFW/glfw3.h
/usr/include/GLFW/glfw3.h is owned by glfw 3.1-1
Find out which .so files are in that package:
$ pacman -Ql glfw | grep 'so$'
glfw /usr/lib/libglfw.so
And, if needed, find the actual file that link points to:
$ readlink -f /usr/lib/libglfw.so
/usr/lib/libglfw.so.3.1
This will depend on your distribution. I believe on Ubuntu/Debian you'd use dpkg-query instead.
Edit: DevSolar points out in a comment that you can use apt-file search <header> and apt-file list <package> instead of dpkg-query -S <header> and dpkg-query -L <package>. apt-file appears to work even for packages that aren't installed (though it seems slower?).
I also noticed that (on my Ubuntu VM at least) that, e.g., libglfw-dev contains the libglfw.so symlink, while libglfw2 contains the actual libglfw.so.2 object.
Once you have a set of .so files, you can check them for whatever function you are interested in:
$ nm -D /usr/lib/libglfw.so | grep "glfwCreateWindow"
0000000000007cd0 T glfwCreateWindow
Note that I pulled this last step from a comment on the previous question and don't fully understand it. Maybe you could even skip the earlier steps and rely on nm and grep alone?
This is not a sure fire way, but it can help in many cases.
Basically, you can usually find the library name at the bottom of the man page.
Eg, man XCreateWindow says libX11 on the last line. Then you look for libX11.so and use nm or readelf to see all exported functions.
Another example, man XShm says libXext at the bottom. And so on.
UPDATE
If the function is in section (2) of the man pages, it's a system call (see man man) and is provided by glibc, which would be libc-2.??.so.
Lastly (thanks Basile), if the function does not mention the library, it is also most likely provided by glibc.
DISCLAIMER: Again this is not a 100% accurate method -- but it should help in most cases.
You can ask gcc to tell you which file it would use for linking like so:
gcc --print-file-name=libX11.so
Sample output:
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so
This file will usually be a symlink, so you'll have to pipe it through readlink or realpath to get the actual file. For example:
readlink -f $(gcc --print-file-name=libXext.so)
Sample output:
/usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
As I commented, you could use gcc to link your program, and then it should be able to accept -lX11 ; by using gcc -v instead of gcc you'll find out what is actually linked and how.
However, you have a much more significant issue than finding the lib*.so.*; most C or C++ APIs are described in header files, and these C or C++ header files also contain symbolic constants (like O_RDONLY for open(2)...) or macros (like WIFEXITED in POSIX wait ...) whose value or expansion you should manually find in header files or documentations. (Quite often, such constants are either preprocessor #define-d constants or enum values). Also, some headers -in particular in C++- contains a lot of inline-d functions (or macros)!
A possible way might be to generate some C files to find all these constants, enums, macros, inlined functions..., and/or to customize the GCC compiler (e.g. with MELT ...) to find them.
So my message is that for better or worse, the C language is deeply tied to Linux & POSIX.
You might restrict yourself to use only syscalls(2) from your assembler code. Then you won't use libX11 and you don't need any header or constant (except the ones for syscalls, starting from <asm/unistd.h>).
BTW, in 2015, coding entirely in assembler for performance reasons is a mistake. The compiler is generating better code than you reasonably can (as soon as you have more than a few hundred machine instructions). In practice, you can code in assembler with GCC by using extended asm instructions in your C functions.
Or are you building your own compiler ? Then you should have told so in your question!
Read also the Program Library HowTo & the Linux Assembly HowTo
I would like to have g++/gcc tell me the paths to everything non-system it is #include-ing in C++ build. Turns out, that is a tough search as Google mus-interprets it about ten different ways.
I want these filenames and paths so I can add them to the search path for Exuberant CTAGS. We have a huge project and if I use ctags on the whole thing it takes about half an hour to generate the tags file and nearly as long for the editor to do a look-up.
We use CMakeLisats to do the compiling. If there is a directive I can paste into the CMakeLists.txt, that would be extra wonderfulness.
I don't really need the default paths and filenames, Johnathan Wakely gave a good tool for that here. I think that pretty much covers the fact that this is a cross compile job. I don't need the cross-system files either.
Try gcc or g++ with the -H option (to the preprocessor part of it). From the doc:
-H
Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the ‘#include’ stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ‘...x’ and a valid one with ‘...!’ .
It tells you all the headers which are included. You may filter out (with grep -v or awk) those that you don't want.
You could also consider developing your GCC plugin to register these headers somewhere (e.g. in your sqlite database), perhaps inspired by this draft report, or the CHARIOT or DECODER European projects. You could also consider using, or extending, the Clang static analyzer.
In contrast to the -M options suggested in Oliver Matthews' answer, it does not tell you more (but gives all the included files).
You need to invoke g++ with the -M option.
From the manual:
Instead of outputting the result of preprocessing, output a rule
suitable for make describing the dependencies of the main source file.
The preprocessor outputs one make rule containing the object file name
for that source file, a colon, and the names of all the included
files, including those coming from -include or -imacros command line
options.
It's worth reading the manual to consider the other -M sub options (-MM and -MF in particular may be of use).
I am a Emacs newbie. I have to trying to search on how to use Emacs for use with large C++ projects particularly to index code and auto-complete function names and behave Eclipse-like. I had been using Vim for some time where I used ctags to index code in my project and Vim used to try auto-completing my code using a drop down menu of options. I am trying to achieve the same with Emacs now. But, during my search, results pointed to CEDET and auto-complete and other 3rd party plugins.
I tried to use ctags with ctags -e -R . and etags, but with no success.
Am I missing a default way of Emacs to achieve the same behavior? Which is the best and easiest way to achieve what I want?
I use CEDET with autocomplete successfully. Basically, autocomplete is the drop-down box provider, and it takes its sources from various things, most interestingly from CEDET (but also from etags and Gnu Global, which I recommend too).
A good starting point for CEDET is http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html
Alex Ott's emacs config is there: https://github.com/alexott/emacs-configs -- it's an useful resource.
Note that you'll need to grab CEDET from bzr, and install/configure autocomplete correctly. I strongly recommend el-get to install autocomplete (and some other stuff too). You'll need to set up generic projects for EDE to have autocompletion working for random C/C++ files not part of a structured EDE project.
You'll have to spend some time to configure emacs, but it pays off. The tool is amazingly productive once set up correctly.
Indexing
You might want to use GNU/global instead of ctags: it supports C++ and is in my opinion more efficient with large projects (especially since you can update the index instead of rebuilding it from scratch). And it still is a lot simpler to use that CEDET/Semantic (which is also a fantastic tool if you spend the time to set it up).
Example use:
$ cd sources
$ gtags -v # create the index
$ cd subdirectory
$ [hack hack hack]
$ global -u # update the index (can be called from anywhere in the project)
In Emacs, activate gtags-mode in the source code buffers to get access to the gtags commands:
gtags-find-tag (M-.) : find the definition of the specified tag in your source files (gtags lets you choose between all possible definitions if there are several, or directly jumps if there is only one possibility)
gtags-pop-stack (M-*) : return to the previous location
gtags-find-rtag : find all uses of the specified tag in the source files
Below is my configuration for gtags, which automatically activates gtags-mode if an index is found:
;; gtags-mode
(eval-after-load "gtags"
'(progn
(define-key gtags-mode-map (kbd "M-,") 'gtags-find-rtag)))
(defun ff/turn-on-gtags ()
"Turn `gtags-mode' on if a global tags file has been generated.
This function asynchronously runs 'global -u' to update global
tags. When the command successfully returns, `gtags-mode' is
turned on."
(interactive)
(let ((process (start-process "global -u"
"*global output*"
"global" "-u"))
(buffer (current-buffer)))
(set-process-sentinel
process
`(lambda (process event)
(when (and (eq (process-status process) 'exit)
(eq (process-exit-status process) 0))
(with-current-buffer ,buffer
(message "Activating gtags-mode")
(gtags-mode 1)))))))
(add-hook 'c-mode-common-hook 'ff/turn-on-gtags)
Automatic completion
I don't know of any better tool than auto-complete. Even if it is not included within Emacs, it is very easily installable using the packaging system (for example in the marmalade or melpa repositories).
It depends what you are looking for in an IDE. I have been using Emacs for a fairly large C++ project. Of course you need to configure emacs to work as you want it to work in a greater extent they any other IDE.
But yes CEDET is a start, even though it is not perfect.
However there is a very good auto complete mode for Emacs http://cx4a.org/software/auto-complete/ it is not intelisense but it should integrate with CEDET in some way to give you a farily good auto complete.
Another important feature that I often use is the function ff-find-other-file to easy jump from header and implementation files.
Then of course you need to roll your own bulid. CEDET has some support for projects, but I have not tested it. However Emacs integrate well with command-line build tools such as make. Errors are printed in a buffer and you can jump to the correct line easily within Emacs.
GDB is also integrates well with Emacs M-x gdb, then just remember the gdb-many-windows command.
I recommend to watch Atila Neves lightning talk at CppCon 2015 titled Emacs as a C++ IDE.
For for details, see my answer to this related question.
See https://emacs.stackexchange.com/questions/26518/sequence-of-packages-to-be-installed-to-make-emacs-an-ide-for-c-c
I use GNU Global and two popular Emacs plugins:
company for code completion
emacs-helm-gtags for code navigation
I need to have some of my C++ classes, functions and namespaces renamed as a part of my build script, which is runned by my CI system.
Unfortunatly a simple sad/awk/gsar/... technique is not enough, and I need smart rename refactoring, that carefully analyses my code.
Actually I found out, that CDT C/C++ rename refactoring does, what I need. But it does it from Eclipse IDE. So I need to find a way to start it from command line, and to make it a part of my CI build script.
I know that Eclipse has eclipsec executable, that allowes running some Eclipse functions from command line (see e.g. here).
But I can't find any suitable documentation for functions, CDT exports to command line. The only thing, I found is the this. But it doesn't solve my problem.
So, I need help to run CDT rename refactoring from command line (or someway like that). If it is not possible, may be someone will advice another tool, that can do rename refactoring for C++ from command line ?
Pragmatic Approach
"I need to have renamed as a part of my build script"
This sounds a bit like a design problem. However, I remember having been guilty of the same sin once writing a C++ application on AIX/Win32: most notably, I wanted to be able to link 'conflicting' versions of shared objects. I solved it using a simple preprocessor hack like this:
# makefile
#if($(ALTERNATIVE))
CPPFLAGS+=-DLIBNAMESPACE=MYLIB_ALTERNATIVE
#else
CPPFLAGS+=-DLIBNAMESPACE=MYLIB
#endif
./obj64/%.o: %cpp
xlC++ $(CPPFLAGS) $^ -o %#
Sample source/header file:
namespace MYLIB
{
class LibService :
{
};
}
As you can see, this required only a single
find -iname '*.[hc]pp' -o -iname '*.[hc]' -print0 |
xargs -0 sed -i 's/OldNamespace/MYLIB/g'
Eclipse Automation
You could have a look at eclim, which does most, if not all, of what you describe, however it targets the vim editor.
What eclim boasts, is full eclipse intergration (completion, refactoring, usage search etc.) from an external program. I'm not fully up to speed with the backend of eclim, but I do know that it works with a eclimd server process that exposes the service interface used by the vim plugin.
I suspect you should be able to reuse the code from eclimd if not just use eclim for your purposes.
We are completing a command-line rename tool for C++, that uses compiler accurate parsing and name resolution, including handling of shadowed names. Contact me (see bio) for further details or if you might be interested in a beta.