I'm wondering if I can compile just a single .c file like check_http.c in de source package of nagios-plugins-1.4.15 in the dir plugins. I'm about to add a piece of code to resolve a problem encountered by PNP4NAGIOS.
I want to compile this check_http and replace the old one in the libexec folder with this new one.
Yes, you can do this. In fact, we have done it here.
Configure up the nagios-plugins source as you would normally do. Then, edit your check_http.c file to make your changes, and from within the plugin source directory, just run 'make check_http' and it will compile just that. If it claims that the file is already up to date, just 'rm check_http' and then 'make check_http'.
If it complains about a missing library (libcoreutils libnagiosplug) or or other .o files, then this is because you have never run the initial compile to make the common libraries. Go back to the base of the source tree, and do 'make all'. Then, go back to the plugins directory and try 'make check_http'.
Related
I'm porting a large project to linux. I wrote all the CMakeLists.txt files, and everything compiles in my machine.
For whatever reason we still use TFS. The old version, not git with TFS.
I'm working in my own branch, but that branch has no build definition for linux. Before I check in, I want to be sure that everything compiles on the server too. So I need to merge my branch to another one, and submit that shelve set to the build job.
In my machine everything compiles fine. But when I run the build in the server, applying a shelveset to the branch that has a linux build definition, I get an error from the build, saying
CMake Error at
/myproject/subproject/CMakeLists.txt:165 (add_library):
Cannot find source file:
/myproject/subproject/IInternalTransactionManager.h
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
Indeed, that file is not there. Cmake complains about the file not being in the sources directory, which is true, because it is in another directory. But the fact is that I'm not asking for it either! My CMakeFiles.txt file does not include that file. That file is a header which is used in a few files, contains only classes definitions (no implementations), and the directory in which myHeader.h resides has been defined in include_directories. My CMakeLists.txt looks something like this:
set(PROJECT_NAME project)
project(${PROJECT_NAME})
include_directories(
../_include
)
set(source_files
main.cpp
file_that_includes_myHeader.cpp
)
add_library( ${PROJECT_NAME} STATIC ${source_files} )
and my file structure is something like:
/myproject/subproject/main.cpp
/myproject/subproject/file_that_includes_myHeader.cpp
/myproject/subproject/CMakeLists.txt
/myproject/_include/myHeader.h
So, why should cmake complaining about a missing file, if such file is not included in the CMakeLists.txt file? And why would this happen only the build in TFS? My guess is that there is something wrong when applying the shelvetset and is not related to my code, but I cannot prove it.
I compared the code after the shelveset is applyied, and still in that version the CMakeLists.txt does not mention myHeader.h
Or, there is some rule about including headers in CMakeLists.txt files which I'm not aware of.
So, after expending too much debuging I contacted the team in charge of the build process. And as it turns out, the building process in the TFS building definition was definetly NOT what I expected. And of course this was not documented.
Our development is mostly in windows (by far). The linux build has a step before building: a script is launched which parses each Visual Studio project file, gets the included files, and substitutes the source files in the CMakeLists.txt files with the one parsed from VS. Right or wrong, is just the way it is.
I could build the linux build in my local machine because everything was done correctly. The windows build worked too, even though the VS project files sometimes included some files which were not in the source directory but in some header only directory, and somehow that compiled. I guess because the directory was defined in the include directory. But When the CMakeLists.txt files were updated, cmake complained (rightly so) about not finding the files.
So, if anybody experiences similar issues, contact your devops team or whoever is in charge of such things.
I have SCons code in which I am using SConscripts to build different directories separately. In my Src directory, my SConscript builds a shared library, and then returns the resulting Node as the Python variable libMyLibrary. I typically use the install option to copy this library to a directory that is on my system's LD_LIBRARY_PATH (I'm using OpenSUSE).
So far, so good. Now, in another directory, Src/Test, another SConscript imports libMyLibrary and builds some Programs using code like this:
env.Program('myProgram', 'myProgram.cpp', LIBS=[env['LIBS'], libMyLibrary])
The program then gets installed to my local bin folder. This code does track the library dependency and build the program, but the problem is that since the library is in a sub-directory (Src), that sub-directory gets included in the linker command. Here is an abbreviated example of the linker command that SCons generates:
g++ -o Src/Test/myProgram Src/Test/myProgram.o Src/libMyLibrary.so
I believe this happens because the Node,libMyLibrary, is essentially a path. The problem is that when I try to run the program, it is not looking for libMyLibrary.so in my library folder, but rather Src/libMyLibrary.so, and of course it doesn't find it.
I do NOT want the libraries I build to be installed in sub-directories of my install folder.
I already add the Src folder to LIBPATH, so SCons adds the -LSrc option to the linker command, but that doesn't solve the problem. My preference would be that when I add a Node, the path should automatically get parsed out to add the appropriate -L and -l options.
I know that I can get around this problem by adding the string 'MyLibrary' to the LIBS variable instead of the libMyLibrary Node, but then I have to explicitly tell SCons that each Program Depends() on libMyLibrary. It seems very inefficient to short-circuit SCons's built-in dependency tracking this way. Does anyone know the correct, SCons-y way to do this?
I'm referring to your latest comment: It looks to me as if this is not really a SCons problem, but more a general linker question (XY problem). Are you perhaps simply searching for RPATH? Please also check this old SO question: scons executable + shared library in project directory
I am getting kind of frustrated with cmake, as I am trying to learn it and use it properly.
Here is my setup:
I have a directory called ~/project. In this directory, I have:
build directory
source directory
includes directory.
CMakeLists.txt file.
The contents of this CMakeLists.txt file is:
cmake_minimum_required(VERSION 2.8)
project(myProject)
subdirs(source)
I also have another CMakeLists.txt in ~/project/source, and its content is:
cmake_minimum_required(VERSION 2.8)
include_directories("~/project/includes")
add_executable(exec entry.cpp)
Now, I go into the build directory which is empty, and do cmake ... This works fine. However I then see a 'source' directory get created as shown here.
Why is this being created? I do not know what is going on. As I understand it, it should not be doing this, it should give me everything I see here, except for the 'source' directory.
Thanks.
Inside your build directory, CMake re-creates the whole directory structure of your project. The rational is, to keep the project structure. Image a bigger project with several levels of subfolders and sources, libraries and tests scattered in a meaningful way. To run a test, you follow the structure where the test's source is located, just in the build directory instead of the source directory.
As your project, at least as far as CMake knows it, is only the source subdirectory, only this folder is created.
If you really have just the source project, I am not sure whether would be better to place the CMake project just inside source.
I can't seem to find much about this, so maybe it isn't possible... or I am searching with the wrong keywords.
Anyway, I have a directory of source. Let's say that there is a folder within Source called Tests and another called Products. I have the usual hierarchy of CMakeLists.txt files so that I can build all the source in each directory and subdirectory, etc... What I want to know is if it is possible to pass a command line argument with cmake so that it will only build the tests folder or the source folder.
e.g. something like cmake TEST ..
Thanks
Of course you can use flags.
if(TEST)
include needed folders
else()
do something else
endif()
And call cmake like this:
cmake -DTEST=1 ..
You can create them as different targets. CMake will configure all of them, but then you can run make test or make product. An example would be:
project(myProject)
add_subdirectory(tests)
add_subdirectory(products)
add_executable(test EXCLUDE_FROM_ALL ${TEST_SRC_FILES})
add_executable(product EXCLUDE_FROM_ALL ${PRODUCT_SRC_FILES})
In each subdirectory you would have a CMakeLists.txt that builds the source file variables. The EXCLUDE_FROM_ALL means that just typing make won't build either tests or products, but you can decide if you want that to happen or not.
To build, you can do make test or make product and it will build only that target (and any dependencies).
So I have scons working with an alternate build location (build/ for my output files, src/ for my input files) and it works great. Except for one thing.
I'm using an IDE (TI Code Composer 4) to debug my program. I point the IDE at the output executable to run it, and what it uses for the source files for debugging is the build/ directory. I don't really care, except when I go to edit the file in the IDE, for example main.cpp, the file is really build/main.cpp which gets clobbered as soon as I run scons again. I have to remember to edit src/main.cpp instead. I am aware of this issue and yet I make the same mistake often.
Is there a way to have scons make the source files it copies into the build path read-only? (I'd ask how to get TI CCS4 to use the right source files when it is debugging an executable, but I doubt I'd get any answers.)
This page has information about wrapping InstallTargets with a chmod call.
FYI, the scons user list is quite active with many knowledgeable people and you can get answers pretty quickly.
You could always tell scons not to duplicate source files in the build directory:
SConscript('src/SConscript', variant_dir='build', duplicate=0)