generic-library/opencv
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
96903dc4ad
opencv/cmake/OpenCVGenPkgconfig.cmake

107 lines
3.9 KiB
CMake
Raw Normal View History

Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
# --------------------------------------------------------------------------------------------
# according to man pkg-config
# The package name specified on the pkg-config command line is defined to
# be the name of the metadata file, minus the .pc extension. If a library
# can install multiple versions simultaneously, it must give each version
# its own name (for example, GTK 1.2 might have the package name "gtk+"
# while GTK 2.0 has "gtk+-2.0").
#
# ${BIN_DIR}/unix-install/opencv.pc -> For use *with* "make install"
# -------------------------------------------------------------------------------------------
if(CMAKE_BUILD_TYPE MATCHES "Release")
set(ocv_optkind OPT)
else()
set(ocv_optkind DBG)
endif()
#build the list of opencv libs and dependencies for all modules
set(OpenCV_LIB_COMPONENTS "")
set(OpenCV_EXTRA_COMPONENTS "")
foreach(m ${OPENCV_MODULES_PUBLIC})
list(INSERT OpenCV_LIB_COMPONENTS 0 ${${m}_MODULE_DEPS_${ocv_optkind}} ${m})
if(${m}_EXTRA_DEPS_${ocv_optkind})
list(INSERT OpenCV_EXTRA_COMPONENTS 0 ${${m}_EXTRA_DEPS_${ocv_optkind}})
endif()
endforeach()
ocv_list_unique(OpenCV_LIB_COMPONENTS)
ocv_list_unique(OpenCV_EXTRA_COMPONENTS)
ocv_list_reverse(OpenCV_LIB_COMPONENTS)
ocv_list_reverse(OpenCV_EXTRA_COMPONENTS)
#build the list of components
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
# Note:
# when linking against static libraries, if libfoo depends on libbar, then
# libfoo must come first in the linker flags.
# world is a special target whose library should come first, especially for
# static link.
if(OpenCV_LIB_COMPONENTS MATCHES "opencv_world")
list(REMOVE_ITEM OpenCV_LIB_COMPONENTS "opencv_world")
list(INSERT OpenCV_LIB_COMPONENTS 0 "opencv_world")
endif()
set(OpenCV_LIB_COMPONENTS_)
foreach(CVLib ${OpenCV_LIB_COMPONENTS})
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
get_target_property(libloc ${CVLib} LOCATION_${CMAKE_BUILD_TYPE})
if(libloc MATCHES "3rdparty")
set(libpath "\${exec_prefix}/share/OpenCV/3rdparty/${OPENCV_LIB_INSTALL_PATH}")
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
else()
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
set(libpath "\${exec_prefix}/${OPENCV_LIB_INSTALL_PATH}")
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
endif()
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
list(APPEND OpenCV_LIB_COMPONENTS_ "-L${libpath}")
get_filename_component(libname ${CVLib} NAME_WE)
string(REGEX REPLACE "^lib" "" libname "${libname}")
list(APPEND OpenCV_LIB_COMPONENTS_ "-l${libname}")
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
endforeach()
# add extra dependencies required for OpenCV
if(OpenCV_EXTRA_COMPONENTS)
changed foreach variable to match naming conventions and dropped intermediate variable, appending directly to the LIB_COMPONENTS list
2013-10-15 20:54:58 +02:00
foreach(extra_component ${OpenCV_EXTRA_COMPONENTS})
Use imported targets for linking to CUDA This retains the desirable quality of not including paths to CUDA libraries from the build system into the config files, and has two major advantages: * It removes the need to use link_directories, which doesn't guarantee that the libraries from the supplied directory will be used (there may be libraries with the same names earlier in the search path). * It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable is used with target_link_libraries, where such entries are treated as linker flags, so doing this is unportable. I remove the support for -L entries from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the future.
2015-03-30 14:16:32 +02:00
if(TARGET "${extra_component}")
get_target_property(extra_component_is_imported "${extra_component}" IMPORTED)
if(extra_component_is_imported)
get_target_property(extra_component "${extra_component}" LOCATION)
endif()
endif()
shortened code to not repeat myself
2013-10-17 20:12:02 +02:00
Use imported targets for linking to CUDA This retains the desirable quality of not including paths to CUDA libraries from the build system into the config files, and has two major advantages: * It removes the need to use link_directories, which doesn't guarantee that the libraries from the supplied directory will be used (there may be libraries with the same names earlier in the search path). * It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable is used with target_link_libraries, where such entries are treated as linker flags, so doing this is unportable. I remove the support for -L entries from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the future.
2015-03-30 14:16:32 +02:00
if(extra_component MATCHES "^-l")
list(APPEND OpenCV_LIB_COMPONENTS_ "${extra_component}")
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
elseif(extra_component MATCHES "[\\/]")
get_filename_component(libdir "${extra_component}" PATH)
get_filename_component(libname "${extra_component}" NAME_WE)
string(REGEX REPLACE "^lib" "" libname "${libname}")
Use imported targets for linking to CUDA This retains the desirable quality of not including paths to CUDA libraries from the build system into the config files, and has two major advantages: * It removes the need to use link_directories, which doesn't guarantee that the libraries from the supplied directory will be used (there may be libraries with the same names earlier in the search path). * It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable is used with target_link_libraries, where such entries are treated as linker flags, so doing this is unportable. I remove the support for -L entries from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the future.
2015-03-30 14:16:32 +02:00
list(APPEND OpenCV_LIB_COMPONENTS_ "-L${libdir}" "-l${libname}")
Only append -l to lib entries with no path and no -l or -L of their own
2013-10-17 20:05:06 +02:00
else()
Use imported targets for linking to CUDA This retains the desirable quality of not including paths to CUDA libraries from the build system into the config files, and has two major advantages: * It removes the need to use link_directories, which doesn't guarantee that the libraries from the supplied directory will be used (there may be libraries with the same names earlier in the search path). * It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable is used with target_link_libraries, where such entries are treated as linker flags, so doing this is unportable. I remove the support for -L entries from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the future.
2015-03-30 14:16:32 +02:00
list(APPEND OpenCV_LIB_COMPONENTS_ "-l${extra_component}")
Only append -l to lib entries with no path and no -l or -L of their own
2013-10-17 20:05:06 +02:00
endif()
Added -l prefix to EXTRA_COMPONENTS when generating pkg-config file
2013-10-14 19:36:07 +02:00
endforeach()
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
endif()
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
list(REMOVE_DUPLICATES OpenCV_LIB_COMPONENTS_)
string(REPLACE ";" " " OpenCV_LIB_COMPONENTS "${OpenCV_LIB_COMPONENTS_}")
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
#generate the .pc file
cmake/OpenCVGenPkgconfig.cmake: rework opencv.pc generation Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gcc Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
2014-10-03 00:32:40 +02:00
set(prefix "${CMAKE_INSTALL_PREFIX}")
set(exec_prefix "\${prefix}")
set(libdir "\${exec_prefix}/${OPENCV_LIB_INSTALL_PATH}")
set(includedir "\${prefix}/${OPENCV_INCLUDE_INSTALL_PATH}")
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
if(INSTALL_TO_MANGLED_PATHS)
set(OPENCV_PC_FILE_NAME "opencv-${OPENCV_VERSION}.pc")
else()
set(OPENCV_PC_FILE_NAME opencv.pc)
endif()
Made the generated file templates' naming more consistent. The general convention is <output file name> + ".in".
2013-11-14 16:14:38 +01:00
configure_file("${OpenCV_SOURCE_DIR}/cmake/templates/opencv-XXX.pc.in"
"${CMAKE_BINARY_DIR}/unix-install/${OPENCV_PC_FILE_NAME}"
Removed all use of the obsolete IMMEDIATE parameter to configure_file. It's not documented, and it does nothing unless CMake 2.0 compatibility is enabled (and it isn't): https://github.com/Kitware/CMake/blob/v2.6.0/Source/cmConfigureFileCommand.cxx
2014-01-29 16:34:02 +01:00
@ONLY)
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
if(UNIX AND NOT ANDROID)
All installed files marked with component names for install customization.
2014-01-17 13:30:31 +01:00
install(FILES ${CMAKE_BINARY_DIR}/unix-install/${OPENCV_PC_FILE_NAME} DESTINATION ${OPENCV_LIB_INSTALL_PATH}/pkgconfig COMPONENT dev)
Global CMake reorganization: [~] Automatically tracked dependencies between modules [+] Support for optional module dependencies [+] Options to choose modules to build [~] Removed hardcoded modules lists from OpenCVConfig.cmake, opencv.pc and OpenCV.mk [+] Added COMPONENTS support for FIND_PACKAGE(OpenCV) [~] haartraining and traincascade are moved outside of modules folder since they aren't the modules
2012-02-03 12:26:49 +01:00
endif()
Reference in New Issue Copy Permalink