I tried to add additional source file in FDK-AAC. But when I autoconf and configure for the compilation, my source file didn't get compiled. Any idea how to make autoconf to include my source file in compilation? Thank you.
Thank you everyone. For those who have the same problem as mine, the thing is there is the template Makefile.am which is used by automake. You just need to include your source file in the Makefile.am to get it compiled by generated Makefile.
Problem solved.
Related
Maybe stupid question, but how do I change directory where cmake files gonna be created, so I can keep my project kinda cleaner.
For example when I run cmake -S. -B./src it is not gonna create files and directories like cmakeChache, cmakefiles and other in my source directory.
Btw I running linux.
I understood how to do it. I just had CMakeLists.txt file and my source c++ code in another directories and I don't know how to set source path to CMakeLists.txt file and c++ source in the same time so I just moved CMakeLists.txt file to source directory and now I don't have to set build path to path of my source code.
The syntax is:
cmake -S <PATH/TO/SOURCE_FILES> -B <PATH/TO/BUILD_OUTPUT>
cmake --build <PATH/TO/BUILD_OUTPUT> --target all
It is recommended that <PATH/TO/BUILD_OUTPUT> is not a sub directory of <PATH/TO/SOURCE_FILES>.
It should be parallel to the sources:
+-PATH
+-TO
+-BUILD_OUTPUT
+-otherstuff
+-SOURCE_FILES
Note: Most CMS(e.g. git) can be configured to not consider generated files.
When I run make binutils/readelf I get the following error:
In file included from readelf.c:43:0:
sysdep.h:23:25: fatal error: alloca-conf.h: No such file or directory
#include "alloca-conf.h"
What dependency am I missing? How do I just build and compile readelf without making the rest of binutils?
What has actually happened is that you do not have a Makefile or at least not one defining binutils/readelf target. But since there is a binutils/readelf.c file, make still ran and tried to compile and link binutils/readelf using its implicit pattern rules... and failed because this source file cannot be built without corresponding configuration.
This is just to add a bit more detail. Long story short, run ./configure and make as suggested in the comments and collect your resulting readelf. Much easier then trying to isolate a solitary item build out of autotools based project. You add -I to CFLAGS to find alloca-conf.h, you'll just run into another problem like that.
I'm trying to implement an open source library that is built using the GNU compiler. (namely, this: https://github.com/mjwybrow/adaptagrams )
I've tried opening and building that source code using VSC++ 6, but it results in over a thousand errors due to the strict nature of the VS compiler I guess. And rather then go through every error and try fix it myself, I was wondering if it's possible to just include the .lib if it is built with the GNU compiler?
EDIT:
Included in the source code linked above is an autogen.sh file.
mkdir -p m4
autoreconf --install --verbose
automake -a --add-missing
./configure
make
Running that with Cygwin results in a few .a library files to be created, which are unusable in VS. Is it ok to just rename these to .lib files?
I've found some stuff online about how to use GCC and create a DLL, but my problem is that I don't know enough about the GNU compiler or makefiles, or the source code in general to be able to change it right now.
Does anybody have any clues on what exactly I'd need to change to get it right? Or even better, has anyone created a DLL using this source code already that would be able to pass it on to me, or let me know what I have to do?
Or could anyone point me towards a similar library that would be compatible with visual studio?
No; you can however build the .dll file with gcc and use the .dll from msvc (with either a hand-crafted include file or a properly formatted one from the beginning, with platform specific import/export macros on top).
Question is similar to this question
Handling header files dependencies with cmake
I have sample program dir having main.c main.h and CMakeLists.txt
main.h contents are
#ifndef MAIN_H
#define MAIN_H
int t=3;
int y=2;
#endif
main.c contents are
#include <main.h>
#include<stdio.h>
int main(){
printf("%d apple",t);
}
and CMakeLists.txt
PROJECT( test )
AUX_SOURCE_DIRECTORY(. test_SRCS)
include_directories(.)
ADD_EXECUTABLE (main ${test_SRCS})
but cmake is not rebuilding main.c on modification of header file.
I want it to auto-generate header file dependency.
Is it possible using cmake ?
if not is there any other tool which can do that ?
As mentioned in my comment, I have tried out your example and things were working fine: if main.h was modified then main.c would be recompiled.
My installation of CMake (version 2.8.0) told me to add
cmake_minimum_required(VERSION 2.8)
to the CMakeLists.txt file, but that is all of the adjustments I needed.
Answering this for others that google search...
I ran into this problem with one of my projects. As it turns out I added the header to the cpp file after running cmake. Re-running cmake fixed the problem. If you run into this, try that and see if it fixes the issue.
From the cmake 2.8.0 documentation of AUX_SOURCE_DIRECTORY:
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually
rerun CMake to generate a build system incorporating the new file.
Why do you want to avoid creating a list of files? Such lists generally do not change frequently.
I'm trying to use SCons to compile a program that requires a set of dependencies which I've installed in a non-standard location.
I've installed the dependencies in /home/dja/ocr. Now I'm trying to compile the main program and can't figure out how to tell SCons where to look for the libraries and headers.
I've tried (amongst others):
scons prefix=/home/dja/ocr
scons includepath=/home/dja/ocr/include libpath=/home/dja/ocr/lib
env LIBPATH=/home/dja/ocr/lib INCLUDEPATH=/home/dja/ocr/include scons
...etc...
The results are always the same:
scons: Reading SConscript files ...
Currently supported OS version: Ubuntu 10.04
Checking for C++ library iulib... no
AssertionError: :
File "/home/dja/ocr/src/ocropus/SConstruct", line 107:
assert conf.CheckLibWithHeader("iulib","iulib/iulib.h","C++");
I haven't been able to find an answer on Google.
What is the correct SCons foo to get this to work?
You need to create an environment and set appropriate variables:
env = Environment(
CPPPATH=['/home/dja/ocr/include'],
LIBPATH=['/home/dja/ocr/lib'],
LIBS=['iulib'])
env.Program('my_executable', Glob('*.c'))
The CPPPATH points to a list of C Pre-Processor Paths (Note: 3 P's). LIBPATH points to where your libraries reside. Finally, LIBS is a list of libraries to link with your program.
Unlike with make and its conventions for certain environment variables or the --with-X options to configure, the author of the SConstruct needs to provide a way for a user to specify overrides. By default, scons doesn't read build variables from the environment.
There are various ways of handling user configuration (see Variables which I just learned about), but I'm not aware of widely honored conventions. And for the user in your position, you need to rely on the author writing build documentation or a decent scons --help description, or resort to reading the SConstruct yourself (which you sometimes have to resort to with badly written unconventional Makefiles).
BTW, I would be happy to be corrected on this if my knowledge of scons is out of date.
It seems it's possible to do this by editing the SConstruct file: http://osdir.com/ml/programming.tools.scons.user/2005-09/msg00060.html
This is pretty lame - is there a better general way?
(In this case, reading the SConstruct file showed there was a special provision for providing a path to the dependency specifically, so I've solved the immediate problem but not the general one.)
I found passing LINKPATH="-L/blah/" as an environmental variable to scons worked, when passing LDFLAGS="-L/blah/" did not.
sudo scons --32 --libpath=/home/test/project/stage/lib/ --cpppath=/home/test/project/boost/ --prefix=/home/test/mongClient/output --dbg=on --opt=on install
Where libpath is for linking the library from non-standard location. cpppath is for including the header files from non-standard location.