so I'm using NB with the C++ plugin and Git version control so I can work with colleagues.
I don't know what files are supposed to be "tracked" and we are getting problems because if we only add the code files to git, new files are not being automatically add to NB but only in the physical folder. We figured out that the configuration file is the problem but if we had it to repository we get another problem, absolute paths to the files.
What is the solution for this?
Cheers
I don't know what files are supposed to be "tracked"
As a rule of thumb:
Source / test files
NetBeans project files nbproject (some files only, see below!)
Possible project related files, that are not generated for each compilation
Makefile
What shouldn't go into git (and therefore onto your gitignore):
build directory
dist directory
within nbproject ignore these:
private dir
The Package-* and Makefile-* files
About the last (Package-* / Makefile-*) files i'm not completely sure - please try with them on gitignore first.
Let's assume such a project - put everything with a (x) on gitignore:
<project>
|
+- build/ (x)
|
+- dist/ (x)
|
+- nbproject/
| |
| +- private (x)
| |
| +- some files (as above)
|
+- src/
|
+- test/
|
+- Makefile
Related
For a fairly complex Visual Studio 2013 solution consisting of many large C++ projects, how can I get the paths to all my source code files that end up in my executable for a specific target platform / architecture? This should include the source code from all my projects the application transitively depends on. Example:
Solution
|
+-- Project: Application (depends on "Library A")
| |
| + File: defs.h
| |
| + File: main.cpp
|
+-- Project: Library A (depends on "Library B")
| |
| + File: libA.h
| |
| + File: libA.cpp
|
+-- Project: Library B
|
+ File: libB.h
|
+ File: libB.cpp
In the above, suppose Application depends on Library A, and Library A depends on Library B. When inspecting the Application project, what I'm looking for is the list of paths to the files defs.h, main.cpp, libA.h, libA.cpp, libB.h, libB.cpp.
I'm looking to rely as much as possible on information that is provided by the build tools, like the exact command line that gets passed to the compiler, or some dependency graph. I do not want to write a script that tries to extract all that information from scratch.
Currently, I'm not interested in dependencies to binary / pre-compiled libraries, but only in the source code files that end up in one way or the other in the final executable.
I have a project tree organized as the following:
MyProjects/ - build - project1 - CMakeLists.txt
| | project2 - CMakeLists.txt
|
| src - project1 - Project1Class1.h
| Project1Class1.cpp
| Project1Class2.h
| Project1Class2.cpp
| more subdirectories ...
project2 - Project2Class1.h
| Project2Class1.cpp
| more subdirectories ...
Imagine that project2 depends on project1. Then project2 uses directly project1 files and does not use a static or dynamic project1 library.
Then project2/CMakeLists.txt finds out the project1 and project2 source files and includes them through a GLOB_RECURSE :
file(
GLOB_RECURSE
source_files
../../project1/
../../project2/
)
This is working in the sense that it correctly builds my projects.
Each time I add a new source file in a new folder, in e.g. file MyNewFolder/myTest.cpp in src/project2/, and type
~/MyProjects/build/project2/$ cmake .
~/MyProjects/build/project2/$ make
Then the file is correctly taken into account by cmake. However, my problem is that every file is recompiled again.
Same thing when I change a source file in project1 and try to compile project2.
Note that I considerably simplified what really is in my CMakeLists.txt. So my question is: based on what I explained about it, is this behavior what CMake is expected to do? And if yes what is the rationale behind it and what should I do for make to only compile the new file? I was not able to find any documentation about it on the internet.
Note: Feel free to discuss the overall source build files organization. Notice that I wanted to keep my build configuration separated from the src/ folder.
Edit: I found this which explains why GLOB and GLOB_RECURSE prevent it to work.
Edit 2: Even with no GLOB, the compilation is done from the begining is other cases (see this question)
You are observing known side effect of file(GLOB_RECURSE ...). I'm not sure why exactly this is happening, but to avoid this most CMake-based projects lists their sources explicitly:
set(source_files
../../project1/Project1Class1.cpp
../../project1/Project1Class2.cpp
...
../../project2/Project2Class1.cpp
../../project2/Project2Class1.cpp
...
)
I started playing around with CMake to create a project with Qt and test it with Google Test. At the moment, I succesfully found a way to compile and link all the required libraries. However, I couldn't find a way to link sources to test files with following project structure:
root
|
+-- CMakeLists.txt
+-- src
| |
| +-- CMakeLists.txt
| +-- MyClass.h
| +-- MyClass.cpp
|
+-- test
| |
| +-- CMakeLists.txt
| +-- MyClassTest.cpp
|
+-- lib
|
+-- gtest-1.6.0
|
+-- CMakeLists.txt
Root CMakeLists.txt contains add_subdirectory for gtest, src and test folders. I have succesfully compiled and run "Hello world" app and simple EXPECT_TRUE(true) test in order to check that each part compiles correctly. Unfortunately, I couldn't find a way to include my source file to tests. Is it possible with the following project structure?
PS I know that it is possible to compile my sources as a library and link it to tests, but I dislike that approach, since it is more appropriate for integration testing, rather then unit testing...
EDIT: Added class names to the tree
You can add a global variable at the level of your root CMakeLists.txt:
set(ALL_SRCS CACHE INTERNAL "mydescription" FORCE)
In the first add_subdirectory(src), you can do:
set(ALL_SRCS ${ALL_SRCS} blabla.cpp CACHE INTERNAL "description")
And in the add_subdirectory(test), you continue with:
set(ALL_SRCS ${ALL_SRCS} bla_test.cpp CACHE INTERNAL "description")
You can then do, add_executable, or library or whatever, with all your sources files.
EDIT: add trick for global variables in CMake.
In the root CMakeLists.txt you can add a include_directories(src) This will then also be used by the tests. Another thing you can do is in the test CMakeLists.txt add a include_directories(${<projectName>_SOURCE_DIR}) where projectName is the name specified using project(myproj) in the src/ CMakeLists.txt (if you specified a project in there of course. Also check the docs about project)
When I move some subdirectory away from project managed by "./configure" and all that things, it tries to get to some "../../configure.ac" and other things and is not easily buildable.
How to extract part of such project and make it independent?
There is two ways to deal with this, create a separate auto-tools build process or do away with the auto-tools and hand code or make a new Makefile.
myprojectfoo
|
+-- src
|
+-- man
|
+-- messages
|
+-- lib
|
+-- include
|
+-- others
Have a look at the illustration above, for a fictitious project called myprojectfoo and is using auto-tools to build a binary called foo. The top-level directory i.e. myprojectfoo will have configure.ac, Makefile.am and Makefile.in, in the subdirectories there would be at least Makefile.am and Makefile.in. The auto-tools will create and execute the make commands to build the project.
Now, from what I'm understanding in what you are trying to do:
myprojectfoo
| \ /
+-- sXc
| / \
+-- man
|
+-- messages
|
+-- lib
| \ /
+-- incXude
| / \
+-- others
You want to take out the src subdirectory and it's include's also. Then in that case, it would be easier to create a separate Makefile (read - no auto-tools) build.. in that case, it would be easier.
The best way I can think of it is, you will have to make that decision ultimately, how big is the subset of the project's sources you want to extract, once you go ahead with that, remove all references to Makefile.am, Makefile.in... and borrow an existing simple Makefile template to build it and invoke it like this
make -f MyMakefile
OR
If you want to build a separate project using that subset using auto-tools:
Create a bare-bones Makefile.am as shown below.
Create a bare-bones configure.ac as shown below...
Run autoscan on the source to pick out the dependencies, add the results of the output file 'configure.scan' to the configure.ac
Run automake (Do this once!)
Run autoconf then. It may complain about missing files such as INSTALL, COPYING etc
Then any subsequent changes to configure.ac, run autoreconf after that, which will execute automake, autoconf, and other supporting auto-tools programs.
Taking a sample of the Makefile.am for Linux...
SUBDIRS = src include
ACLOCAL_AMFLAGS = -I m4
Taking a sample of the configure.ac for Linux...
AC_PREREQ(2.63)
AC_INIT([mysubsetprojectfoo], [0.1a], [foo#bar.baz])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE([-Wall -Werror])
AM_GNU_GETTEXT_VERSION([0.17])
AM_GNU_GETTEXT([external])
AM_CFLAGS=
# Checks for programs.
AC_HEADER_STDC
AC_PROG_CC
AC_ARG_ENABLE([debug],
[ --enable-debug Turn on debugging],
[case "${enableval}" in
yes) debug=true ;;
no) debug=false ;;
*) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
esac],[debug=false])
AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])
# Checks for libraries.
AC_CHECK_LIB([mylib], [mylib_function], [:])
if test "$mylib" = :; then
AC_MSG_ERROR([MyLib is missing.\
This can be downloaded from 'http://www.foo.baz'])
fi
AC_CONFIG_HEADERS([config.h])
# Checks for header files.
# FROM running 'autoscan' on the source directory
AC_CHECK_HEADERS([arpa/inet.h fcntl.h libintl.h locale.h netinet/in.h stdlib.h string.h sys/ioctl.h sys/socket.h syslog.h unistd.h])
# Checks for typedefs, structures, and compiler characteristics.
AC_C_INLINE
AC_C_CONST
AC_TYPE_SIGNAL
AC_TYPE_PID_T
AC_TYPE_UID_T
AC_TYPE_SIZE_T
# Checks for library functions.
AC_FUNC_FORK
AC_FUNC_MALLOC
AC_CHECK_FUNCS([atexit inet_ntoa memset regcomp socket strdup strerror])
AC_CONFIG_FILES([Makefile src/Makefile include/Makefile])
AC_OUTPUT
The commands for the auto-tools, is top of my head and I may have missed something..feel free to point out by placing a comment on this at the bottom of this post and it will be amended accordingly.
I'm using qmake for building a project of mine. I have been trying to set the DESTIR variable of qmake with a value that depend of the compiler used. Actually, I want that the binary of my project, after builded, be placed in a directory that has the name of the compiler used to build it.
Something like this... My current directory tree for my project is
- Project
| - src
| - include
| - bin
| |- binary_file
I wanted it to be like this
- Project
| - src
| - include
| - bin
| | - gcc-4.3.4
| | |- binary_file
Can I do this using qmake?
In the src/src.pro file, or wherever you set the DESTDIR
# compiler used
QMAKE_CXX = g++-4.3
# PROJECT_ROOT defined in .qmake.cache as $$PWD, in the Project root directory
DESTDIR = $$PROJECT_ROOT/bin/$$QMAKE_CXX/
If you don't want to set the compiler version, you can query it dynamically. I don't know if there is any general c++/qmake solution for it, but with g++ you can use -dumpversion:
CXX_VERSION = $$system($$QMAKE_CXX -dumpversion)
DESTDIR=$$PROJECT_ROOT/bin/$$QMAKE_CXX-$$CXX_VERSION/