automake

gcov: producing .gcda output from shared library?

為{幸葍}努か 提交于 2019-11-29 21:25:27
Is it possible to produce gcov data files ( .gcda files) by running an executable linked to a shared library built with the --coverage option? Basically, I have the main library consisting of multiple c++ files compiled into one shared library and then a subdirectory called "test" containing a test program that links to and tests the main library. Everything compiles fine and the .gcno files are produced for both the library source files and the test source files. The .gcda files are only produced for the test source files though, but I really need them for the actual source files that are

GNU Autotools: rebuild without version info

对着背影说爱祢 提交于 2019-11-29 18:52:55
问题 I need to build a lib that is configured with autotools. The usual configure && make && make install steps produce versioned shared lib, something like libfoo.so.x.x Is it possible to modify configure.ac or Makefile.am (and of course follow up with autoreconf ) so that un-versioned lib is build. Thank you! 回答1: Yes, assuming that the library is built with libtool , you can remove the version information by adding the -avoid-version flag to the library's LDFLAGS. For example, if before there

How to generate a source file when building using autotools

时光总嘲笑我的痴心妄想 提交于 2019-11-29 06:34:37
With Make, I do something like generated.c: input.txt generator ./generator input.txt > generated.c How would I get equivalent functionality out of autotools? (removing generated.c on cleaning would also be a bonus). I'm assuming that input.txt is a source file that is distributed, that you do not want to distribute generated.c (i.e., it must be built by each user), and that generator is a program built by your package too. EXTRA_DIST = input.txt bin_PROGRAMS = prog noinst_PROGRAMS = generator # Source files for the generator generator_SOURCES = generator.c ... # Source files for prog prog

Automake generating binaries to bin/ instead of in src/

醉酒当歌 提交于 2019-11-29 05:12:35
问题 I searched for the answer to this question but couldn't find any good. Maybe they're old and something has changed, so I ask again. I have a directory structure as: my_project src bin I want that, when I do make in the root dir, the binaries are put in ./bin, instead of cluttering ./src. But how? EDIT: I am using C++. My Makefile.am has nothing special. Just the bin_PROGRAM and _SOURCES variables. When I run make, the binaries generated are put into ./src. I simply want them in ./bin. 回答1:

Placing header files in a subdirectory of /usr/include with automake?

前提是你 提交于 2019-11-29 03:05:57
问题 If I write a library, and have header files for development included, and have a src/Makefile.am like this: AM_CFLAGS = -std=c99 -Wall -Werror -Os lib_LTLIBRARIES = libmylibrary.la libmylibrary_la_SOURCES = a.c b.c include_HEADERS = a.h b.h Everything works nicely. However, a.h and b.h are installed directly under /usr/include (or /usr/local/include ). What should I do to get them installed, in a subdirectory specific to my library, e.g. /usr/include/mylibrary ? 回答1: As well as pkginclude

gcov: producing .gcda output from shared library?

前提是你 提交于 2019-11-28 19:06:21
问题 Is it possible to produce gcov data files ( .gcda files) by running an executable linked to a shared library built with the --coverage option? Basically, I have the main library consisting of multiple c++ files compiled into one shared library and then a subdirectory called "test" containing a test program that links to and tests the main library. Everything compiles fine and the .gcno files are produced for both the library source files and the test source files. The .gcda files are only

How to create a shared library (.so) in an automake script?

一个人想着一个人 提交于 2019-11-28 18:41:47
given some source file test.cpp I would like to create a shared library libtest.so . I am trying to do this within the scope of an automake file however I cannot seem to get this to work. For example under g++ I do the following: g++ -shared -fPIC test.cpp -o libtest.so then i can create another file that will depend on the shared library as follows: g++ mytest.cpp libtest.so -o blah I have read that automake only supports making shared libraries via libtool. I have tried to get my automake scriupt to work as follows but it never seems to produce an .so . The closest i have gotten is for it to

How to overcome “'aclocal-1.15' is missing on your system” warning?

孤者浪人 提交于 2019-11-28 15:42:31
Im trying to run a c++ program on github. (available at the following link https://github.com/mortehu/text-classifier ) I have a mac, and am trying to run it in the terminal. I think I have downloaded autoconf and automake but am not sure. To run the program I am going to the correct folder in terminal then running ./configure && make But I get the error: WARNING: 'aclocal-1.15' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: http://www.gnu.org

GNU autotools: Debug/Release targets?

て烟熏妆下的殇ゞ 提交于 2019-11-28 15:11:30
I've been looking for this for a while: I'm currently converting a medium-size program to autotools, coming from an Eclipse-based method (with makefiles) I'm always used to having a "debug" build, with all debug symbols and no optimizations, and a "release" build, without debug symbols and best optimizations. Now I'm trying to replicate this in some way with autotools, so I can (perhaps) do something like: ./configure make debug Which would have all debug symbols and no optimizations, and where: ./configure make Would result in the "release" version (default) PS: I've read about the --enable

Directory structure for a C++ library

*爱你&永不变心* 提交于 2019-11-28 15:04:16
I am working on a C++ library. Ultimately, I would like to make it publicly available for multiple platforms (Linux and Windows at least), along with some examples and Python bindings. Work is progressing nicely, but at the moment the project is quite messy, built solely in and for Visual C++ and not multi-platform at all. Therefore, I feel a cleanup is in order. The first thing I'd like to improve is the project's directory structure. I'd like to create a structure that is suitable for the Automake tools to allow easy compilation on multiple platforms, but I've never used these before. Since