Is it possible to include other type of file in the search result(e.g find the value of CFLAG in the makefile)? Thanks.
Cscope is an excellent tool, but it really only understands C. (And boy, I wish it understood more C; I can't tell you how often I wished I could use Cscope to find a definition of a structure.)
Exuberant Ctags, on the other hand, understands a lot of languages (42 by my ctags --list-languages), one of which is Make.
Run ctags -R . to build a tags database of your source. (ctags has many command line options to configure how it works but this simple invocation works for me in a variety of projects.) Then you can run vim -t CFLAGS to jump right to the definition of CFLAGS in the Makfile. (It also enables the simple ctrl+] lookup in vim -- see vim's :help CTRL-] for details.)
I usually use cscope, ctags, and gid all together in my own source navigating -- each tool does different enough things that most of my needs can be met with one of them -- the trick is figuring out which task is best suited to which tool.
There is a ruby gem that is cscope-like but supports ruby and golang. It is also extensible, so other languages can be added relatively easily.
http://rubygems.org/gems/starscope
Related
I always used ctags -nR to generate ctags and believed that this should be sufficient. But I now find that its struggling with C++ code where there are too many matches. Does it need more options to be sent in the command line to make it efficient.
I find eclipse to be a bit better although I believe it needs location of headers etc to be specified for existing projects with Makefile.
ctags -nR
Is this any different from exuberant ctags or is it just an improvement.
Request to not reject or close this question as a non programming question because I am sure programmers use such tools extensively and people in S.O would be the right audience to be able to answer this for they would have used it too as Linux programmers.
I'd struggled with this as well.
The problem here is certainly the C++ part.
ctags does not support it that well and many times it finds string matches instead of global definitions. What really worked for me was to replace standard/exuberant ctags with universal-ctags. C/C++ support has been polished a lot. It does work with additional languages by default. I've been using it mainly for Go and C and it does work like a charm.
Here is the link:
https://github.com/universal-ctags/ctags
If you have your ctags environment set up, probably you only need to run the standard configure/make/make install and you're good to go!
Sorry for this newbie question.
Context:
I have just created my own library (using CMake):
libmyownsomething.a <--- static version of the compiled library
libmyownsomething.so <--- dinamic version of the same library
libmyownsomething.h <--- the header file to be included in other project
Questions:
Where is the right place where the files should be placed? ( I guest /usr/local/include/ and /usr/local/lib/
How to compile other lib/projects against this one by inserting only #include <myownsomething.h> and a right flag LDFLAGS=-lmyownsomething?
To be able to link agains your library with just -lmyownsomething, you need to have libmyownsomething.so (or .a, for static linking) in one of the directories you linker searches by default.
I found this in texinfo documentation for GNU ld (library search path in linker script):
'SEARCH_DIR(PATH)'
The 'SEARCH_DIR' command adds PATH to the list of paths where 'ld'
looks for archive libraries. Using 'SEARCH_DIR(PATH)' is exactly
like using '-L PATH' on the command line
Now, GNU ld (ld.bfd to be precise) uses a default linker script, which can be obtained with --verbose. Let's see what search dirs there are by default (on my system, anyways -- that might well depend on configuration; if you are going to distribute your library, you probably want to make the most portable choice):
$ ld --verbose |& grep SEARCH_DIR
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib");
To answer the question about #includeing files, you need to consult the compiler documentation, or perhaps the POSIX standard. (However, I'd recommend either going with the simplest choices -- see below -- or providing a configurable way to install your files e.g. with --prefix build time option. Then the user/packager can decide the best place to put them for themselves. But nothing keeps you from providing sane defaults. Same goes for libraries, but I tried to address that part of the question exactly how it was asked.)
Generally, this stuff varies from system to system, but they usually follow the Filesystem Hierarchy Standard. I think, /usr/include and /usr/lib is the safest choice. Another good practice is using e.g. pkgconf mechanism.
Hope this helps. I really should have asked about your use-case first: who are you going to distribute your software to, and how? Anyway, be sure to post comments. Also, I wonder if this is Stackoverflow material; perhaps it needs moving some place else.
I am working with the Ruby source which has a configure.in script with the following line AC_CHECK_FUNCS(clock_gettime)
On my system it WILL find such a function and Ruby will go ahead and build a binary that depends on this function. However, this function is non-portable to other operating systems so i would like to tell the ./configure script NOT to use this function even if it does find it.
It would be perfect if i can instruct ./configure not to use this function by a command line option, i heavily prefer not to modify the configure.in script if possible. My question is, how do I do this? I can't seem to find the correct command line option to use.
My question is, how do I do this? I can't seem to find the correct command line option to use.
First, there is good advice in the comments: for best results, build on the oldest system you can find (or set up) and try to reduce the dependencies as much as possible. glibc is good about symbol versioning and compatibility, but many other libraries are not.
That said, if you really want to circumvent a check, the way to do it is to pre-populate a cache file with the results you want. One simple way to make the cache is to run configure, then edit it, then re-run configure.
The cache variable naming scheme is documented, but normally you can find what you want by just searching for the function name in config.cache.
Maybe it's even possible to set the cache variable on the configure command line -- but I have never tried this.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.
I have a large legacy codebase with very complicated makefiles, with lots of variables. Sometimes I need to change them, and I find that it's very difficult to figure out why the change isn't working the way I expect. What I'd like to find is a tool that basically does step-through-debugging of the "make" process, where I would give it a directory, and I would be able to see the value of different variables at different points in the process. None of the debug flags to make seem to show me what I want, although it's possible that I'm missing something. Does anyone know of a way to do this?
Have you been looking at the output from running make -n and make -np, and the biggie make -nd?
Are you using a fairly recent version of gmake?
Have you looked at the free chapter on Debugging Makefiles available on O'Reilly's site for their excellent book "Managing Projects with GNU Make" (Amazon Link).
I'm sure that remake is what you are looking for.
From the homepage:
remake is a patched and modernized version of GNU make utility that adds improved error reporting, the ability to trace execution in a comprehensible way, and a debugger.
It has gdb-like interface and is supported by mdb-mode in (x)emacs which means breakponts, watches etc. And there's DDD if you don't like (x)emacs
From the man page on make command-line options:
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute them.
-d Print debugging information in addition to normal processing.
The debugging information says
which files are being considered for remaking,
which file-times are being compared and with what results,
which files actually need to be remade,
which implicit rules are considered and which are applied---
everything interesting about how make decides what to do.
--debug[=FLAGS] Print debugging information in addition to normal processing.
If the FLAGS are omitted, then the behaviour is the same as if -d was specified.
FLAGS may be:
'a' for all debugging output same as using -d,
'b' for basic debugging,
'v' for more verbose basic debugging,
'i' for showing implicit rules,
'j' for details on invocation of commands, and
'm' for debugging while remaking makefiles.
I'm not aware of any specific flag that does exactly what you want, but --print-data-base sounds like it might be useful.
remake --debugger all
More info https://vimeo.com/97397484
https://github.com/rocky/remake/wiki/Installing
There is a GNU make debugger project at http://gmd.sf.net which looks quite useful. The main feature supported by gmd is breakpointing, which may be more useful than stepping. To use this, you download gmd from http://gmd.sf.net and gmsl from http://gmsl.sf.net, and do an 'include gmd' in your makefile.