1. 14 Jan, 2016 1 commit
  2. 17 Jul, 2015 1 commit
  3. 16 Jul, 2015 1 commit
  4. 02 Jul, 2015 1 commit
  5. 29 Jun, 2015 1 commit
  6. 09 Jan, 2015 1 commit
  7. 17 Dec, 2014 1 commit
  8. 23 Oct, 2014 1 commit
  9. 30 Sep, 2014 1 commit
  10. 07 Aug, 2014 2 commits
  11. 27 Jul, 2014 2 commits
  12. 15 Jul, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Fixed GCC compatability of scripting module: · 92c3bdef
      Christian Schulte zu Berge authored
      * 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
  13. 10 May, 2014 4 commits
    • Artur Grunau's avatar
      FindLua: only set LUA_FOUND if CAMPVIS_BUILD_LIB_LUA is ON · 2a946aa2
      Artur Grunau authored
      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
    • Artur Grunau's avatar
      Add support for automatic registration of Lua pipelines · c2348225
      Artur Grunau authored
      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
      References #1
    • Artur Grunau's avatar
      Fix out-of-tree and Visual Studio builds · 8079c98c
      Artur Grunau authored
      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
      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
    • Artur Grunau's avatar
      CMake skeleton of the scripting feature · 82a6d86c
      Artur Grunau authored
      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.
  14. 29 Apr, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Fixed converter registration in statically linked builds: · b0e1aaed
      Christian Schulte zu Berge authored
      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
  15. 07 Apr, 2014 1 commit
  16. 06 Apr, 2014 1 commit
  17. 05 Apr, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Updated CMake build scripts: · 792e2d52
      Christian Schulte zu Berge authored
      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.
  18. 17 Mar, 2014 1 commit
  19. 16 Mar, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Updated and refactored CAMPVis module build system: CAMPVis module .cmake... · 689d5439
      Christian Schulte zu Berge authored
      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
  20. 10 Mar, 2014 1 commit
    • Artur Grunau's avatar
      Replace CAMPVIS_SHARED_LIBS with BUILD_SHARED_LIBS · 9c6f117b
      Artur Grunau authored
      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
  21. 01 Mar, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Added C4251 to the ignore list for MSVC warnings, occuring due to missing... · dc70251d
      Christian Schulte zu Berge authored
      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
  22. 18 Feb, 2014 1 commit
  23. 15 Feb, 2014 1 commit
    • Artur Grunau's avatar
      Improve support for NMake-based builds · 5fbabbf9
      Artur Grunau authored
      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.
  24. 07 Feb, 2014 1 commit
    • Artur Grunau's avatar
      Build TGT as a shared library by default · 8beb8280
      Artur Grunau authored
      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.
  25. 02 Jan, 2014 1 commit
  26. 13 Dec, 2013 1 commit
  27. 02 Dec, 2013 1 commit
  28. 21 Nov, 2013 2 commits
  29. 18 Nov, 2013 1 commit
  30. 17 Nov, 2013 2 commits
    • Artur Grunau's avatar
      Enable the Vis module by default · d0f1cdb1
      Artur Grunau authored
      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
    • Artur Grunau's avatar
      Implement a dependency system for CAMPVis modules · e1551c26
      Artur Grunau authored
      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
      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
  31. 16 Nov, 2013 1 commit
    • Artur Grunau's avatar
      Make the regex used to detect pipelines more permissive · f51cf570
      Artur Grunau authored
      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
  32. 29 Oct, 2013 1 commit
  33. 16 Oct, 2013 1 commit