GitLab

* saved CMake config now also exports the symbol ${CAMPVIS_APPLICATION_LIBRARIES}
* Property widget registration moved to a separate cpp file. This allows external programs to include property widgets' header files without re-registering them.

Disabling GCC warning for using deprecated functions as we don't use this feature of GCC and ITK runs mad with these warnings.

Cleaned up CMake scripts and added correct export definitions so that now CAMPVis can easily imported into other CMake projects through FIND_PACKAGE(CAMPVis).

Removed generation of obsolete gen_converterregistration.h file through CMake since converter registration now entirely relies on explicit template specialization.

refs #386

* Updated CMake scripts to work with new CMake 3 and TBB 4.3

If you need one of these two C++11 headers, include <ext/threading.h> instead, which will use C++11 headers if present or TBB's compatibility layer otherwise.

closes #567

* CMake build files now support unix builds
* SWIG interface files and Lua wrappers are now fully C++ compliant to comfort GCC
* Hacked shared/static builds of the campvis-modules module even more, but now it works on both MSVC and GCC

The FindLua CMake script would previously set LUA_FOUND if the directory
containing the source code of Lua existed without checking if it was
actually part of the build. This could lead to compilation errors if
CAMPVIS_BUILD_LIB_LUA was disabled.

Add an additional check to FindLua to only set LUA_FOUND if
CAMPVIS_BUILD_LIB_LUA is ON and the directory containing the source code
of Lua exists.

References #1

As there's currently only one Lua pipeline, we could so far get away
with storing it in the `scripting` directory, giving it a generic name
and registering it manually. However, this approach won't work anymore
once additional Lua pipelines start to be implemented.

To support multiple Lua pipelines, implement a registration mechanism
for scripted pipelines based on PipelineFactory and similar to
PipelineRegistrar. It scans each active module's `pipelines` directory
for Lua pipelines, parses them and generates a registration header that,
when included, registers them with PipelineFactory.

As a result of the above, the test Lua pipeline had to be moved to
`modules/preprocessing/pipelines/` and could be renamed
ResamplingDemoLua.

References #1

Out-of-tree builds were broken due to Lua and Swig header files not
being correcly included. The state of Visual Studio builds was even
worse: they failed because Lua modules, scripts and libraries were
misplaced.

The issues mentioned above have been fixed by making the build system
properly deal with out-of-tree builds and multi-config generators.

References #1

An option to enable CAMPVis scripting has been added to the top level
CMakeLists.txt. Moreover, a minimal sub-project for the scripting
feature has been created. There's also a new CMake macro, FindLua, that
locates Lua's include and library files.

Statically linked builds strip all unused objects from their sources. This would be the case for the converters since they are nowhere called explicitly. In order to fix that, we use the same pattern as with the pipeline registration: The CMake build scripts parse all headers for an explicit template instantiation of a ConversionFunctionRegistrar. All these headers are included from the generated gen_converterregistration.h file, which is itself included from imagerepresentationconverter.cpp and thus gets compiled into the final executable also on static linking.

refs #474
refs #553

Fixed CMake build scripts to better handle default enabled modules and specifically disabled modules.

Removed ITK dependency from CmBatchGeneration pipeline and replaced Gaussian computation with GlGaussianFilter processor.

Module file parsing now supports new fields "ThisModApplicationSources", "ThisModApplicationHeaders", and "ThisModApplicationToBeMocced". These files will be added to the campvis-application package (instead of to the campvis-modules package) and thus for instance allow a module to declare property widgets in a non-intrusive way.

Little bug fix in glvesselnessfilter.frag shader.

Fixed MSVC builds not supporting shared linking against module sublibs (as campvis-modules is built statically). As workaround RandomWalksLib and nlopt-stripped are forced to be build static.

refs #385

Updated and refactored CAMPVis module build system: CAMPVis module .cmake files now define two additional Variables:
* ThisModStatus defines the status of the module and should be one of STABLE, TESTING or EXPERIMENTAL
* ThisModExternalDependencies defines, whether this module has further external dependencies that are not shipped

The main CAMPVis build system now ships a new enumeration option CAMPVIS_DEFAULT_ENABLED_MODULES, which can be one of "NONE" "STABLE_NO_DEPENDENCIES" "STABLE_WITH_EXTERNAL_DEPENDENCIES" "TESTING" and "ALL". The INCLUDE_MODULE() function in the build scripts will evaluate the modules' status information and enable every module that matches the specified value.

ATTENTION: Due to these changes in the build system, the modules' cmake files should put their setup block into an IF(ModuleEnabled) block, since the file is also parsed, when the module is not enabled (in order to gather the status information).

closes #385

CAMPVis used a custom option, CAMPVIS_SHARED_LIBS, to determine whether
shared or static libraries should be built. This option partially
duplicated the functionality of one of CMake's standard flags,
BUILD_SHARED_LIBS. The two could get out of sync, and because CMake only
consults BUILD_SHARED_LIBS when deciding how to build a library target,
it was possible to get inconsistent and broken build configurations.

To prevent that, add BUILD_SHARED_LIBS as an option to CAMPVis' main
CMakeLists and replace all references to CAMPVIS_SHARED_LIBS with
BUILD_SHARED_LIBS. This makes BUILD_SHARED_LIBS the only flag that
controls whether shared or static libraries are built.

References #367

Added C4251 to the ignore list for MSVC warnings, occuring due to missing template instantiations of the standard library used in public interfaces of tgt and campvis code. Even though articles such as <http://support.microsoft.com/kb/168958/en-us> provide a clean solution to fix these warnings, I decided that exporting bazillions of std library templates is not worth the effort. As we do not plan to ship TGT without the rest to a variety of systems, the missing exports won't be a problem.
BTW: The original tgt library build scripts also deactivate the warning. :)

closes #376

To build CAMPVis using NMake one had to manually copy several external
DLLs into the CMake output directory. There were 2 reasons for that:
- our macros treated NMake as a compiler and didn't try to detect what
  compiler NMake will actually use; as a result, they couldn't find the
  right external DLLs for NMake-based builds
- Visual Studio manages build types independently of CMake and always
  outputs into a build-type-specific sub-directory of the CMake output
  directory — that's where we place external DLLs; NMake, on the other
  hand, relies on CMake for build type selection and will output
  directly into the CMake output directory; due to this discrepancy,
  NMake-based builds couldn't find the external DLLs that were copied
  into the build directory

As many popular IDEs (e.g. Qt Creator, Code::Blocks, Eclipse CDT) rely
on NMake to build projects on Windows, it makes sense to have a working
support for NMake in our build system.

Update our compiler detection macros and adjust the CMake output
directory to match that of Visual Studio when NMake is used to improve
the support for NMake-based builds.

This commit explicitly marks TGT to be built as a shared library and
adds several missing TGT_API annotations to TGT classes that are
required by other CAMPVIS modules.

Added smallHeart.mhd sample volume to repository, all demo pipelines in vis module refer to this file. Hence, all vis pipelines should work out of the box from now.

 * Added a stripped version of NLOPT sources as external library, so that the registration module can be built right away.
 * Some minor improvements in CMake files

fixed CMake error introduced in e1551c26: CAMPVIS_HAS_MODULE_XYZ was no longer defined by CMake

Issue #250: Make Qt dependency in tgt optional (not needed when building CAMPVis without application)

No modules were previously enabled by default. As a result, the
application wasn't very useful in the default configuration.

Enable the Vis module by default to make the CAMPVis application
functional out of the box. Additional modules can be marked as default
in the future using the mechanism (SET_DEFAULT_MODULES) introduced in
this commit.

Closes #144

There used to be no way to specify what other modules each module
required in order to work. This led to either compilation or linker
errors that were often not easy to understand.

Introduce a new module-level CMake variable, ThisModDependencies, that a
module can set in its CMake file to indicate what other modules need to
be enabled for it to compile and work properly. If defined,
ThisModDependencies should be a list of strings — the names of required
modules.

Once all available modules have been analysed, the collected dependency
information is used to activate (if necessary) the dependencies of every
enabled module. Transitive and circular dependencies are already
supported in this initial version of our module dependency system.

Unfortunately, when a module gets enabled in the CMake GUI, its
dependencies are only resolved once the Configure button is clicked and
CMake runs again. This is a limitation of CMake in that all
configuration happens offline and it's not possible to react to value
changes immediately.

References #144

Automatic pipeline registration would fail for certain valid ways of
declaring a pipeline:
- if the base pipeline class was qualified with a namespace
- if the pipeline inherited from additional classes
- if the declaration followed coding conventions different than CAMPVis'
  (e.g. no space before :, { on a new line)

Make the regex used to detect pipelines more permissive to handle the
above cases.

Closes #233