It would be helpful if there were a few simple host-config files for the blt-test project embedded in ./cmake/blt-test/.

I'd like to add a simple host-config file for a simple gcc-based configuration as well as a file for a bg/q based configuration.

Should be moved into Axom.

blt_add_library( NAME vtkh_par SOURCES ${vtkh_sources} ${vtkh_par_sources} $<TARGET_OBJECTS:lodepng> HEADERS ${vtkh_par_headers} DEPENDS_ON ${vtkh_thirdparty_libs} mpi icet)

This works without CUDA, but fails when one of the thirdparty_libs is CUDA.

Call Stack (most recent call first): blt/cmake/thirdparty/FindCUDA.cmake:1723 (CUDA_WRAP_SRCS) blt/cmake/BLTMacros.cmake:332 (cuda_add_library) vtk-h/CMakeLists.txt:96 (blt_add_library)

CMake Error at blt/cmake/BLTMacros.cmake:392 (get_source_file_property): Cannot find source file:

`$<TARGET_OBJECTS:lodepng>`

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
Call Stack (most recent call first):
vtk-h/CMakeLists.txt:96 (blt_add_library)

CMake Error at blt/cmake/thirdparty/FindCUDA.cmake:1548 (add_custom_command): add_custom_command called with OUTPUT containing a "<". This character is not allowed.
Call Stack (most recent call first): blt/cmake/thirdparty/FindCUDA.cmake:1723 (CUDA_WRAP_SRCS) blt/cmake/BLTMacros.cmake:332 (cuda_add_library) vtk-h/CMakeLists.txt:130 (blt_add_library)

to fruit-3.4.1

Although we are building gbenchmark and the blt_benchmark_smoke test when blt is configured with ENABLE_BENCHMARKS=ON, we are not actually running the benchmark smoke test in our CI builds.

To do so, we need to add

 make run_benchmarks

to the CI builds.

When I include blt in my CMakeLists.txt I get the following error:

CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILE_OBJECT
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_CXX_LINK_EXECUTABLE

I cloned blt from master at 33b5245 before vendoring it in my project.

Without blt, there are no issues. Any thoughts? Should I try the release version?

If BUILD_SHARED_LIBS is off on windows -- get we static vs dynamic linking issues related to gtest and gmock.

gtest.lib(gtest-all.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in blt_gtest_smoke.obj

gtest and gmock should be using our BUILD_SHARED_LIBS option, so we may need to set some other options (or compiler defines).

Note: to get shared libs to work, I had to add:

-DGTEST_CREATE_SHARED_LIBRARY=1

When compiling gtest and gmock

and

-DGTEST_LINKED_AS_SHARED_LIBRARY=1

for targets linking it

I tried an obvious set of defines (setting those each to 0) for the shared case, but that wasn't the right magic.

The FORD project is pretty awesome, and is a documentation solution built specifically for Fortran source code. It would be great to add support to blt for FORD. It can be configured in such a way as to be mostly comparable with Doxygen source file markup too.

Would you accept a PR implementing this, if I can find the time at some point? (Not likely to happen soon, though.)

Thanks!

cuda_wrap_srcs is more flexible than cuda_add_library.

Basically, we can use it to create an object lib for the nvcc compilation results, and then use that with the normal CMake add_library.

This is the approach we took in Strawman (https://github.com/llnl/strawman)
https://github.com/LLNL/strawman/blob/develop/src/strawman/CMakeLists.txt

It doesn't fix the overall issues with not being able to set specific properties for cuda targets after they are create, but it would help us create a clean solution to issues like #74 and #60

@davidbeckingsale what do you think?

Examples support is an Axom-ism, should be moved into Axom's CMake

# Set the path were all example test executables will go
set(EXAMPLE_OUTPUT_DIRECTORY
    ${PROJECT_BINARY_DIR}/examples
    CACHE PATH
    "Directory where example executables will go in the build tree"
    )

To expose the full dependency structure to cmake, we should explore using fully described imported targets in blt_register_lib.

This already works for exported then imported lib targets for tpls built with CMake.

Make sure this also works for header only libraries and tpls that are simply registered.

This support may require CMake version greater than 3.3.

Matt Larsen observed that our flood of vars prefixed with BLT_ clutters things when using ccmake or cmake-gui

On obvious place to improve is in the blt_register_lib macro, where we have several per-lib bookkeeping vars that could be marked as advanced:

BLT_FOO_DEPENDS_ON
BLT_FOO_INCLUDES
BLT_FOO_FORTRAN_MODULES
BLT_FOO_LIBRARIES
BLT_FOO_COMPILE_FLAGS
BLT_FOO_LINK_FLAGS
BLT_FOO_DEFINES

Add .f90 .F90 to the non cuda source files

The name path is ambiguous in this case, we want use ZZZ_DIR for the case where we are looking for some standard directory layout, and ZZZ_EXECTUABLE when we point directly to a tool.

google mock should be harmless vs plain google test, however I have an instance where gmock_smoke is crashing. I do want to get to the bottom of this, but I am not actually using google mock - so it would be nice to be able to turn it off.

The call of blt_setup_target inside blt_add_library for header-only libraries needs to be reworked. You can only add INTERFACE dependencies to header-only libraries. Otherwise you get the following error:

CMake Error at blt/cmake/BLTPrivateMacros.cmake:155 (target_link_libraries):
INTERFACE library can only be used with the INTERFACE keyword of
target_link_libraries
Call Stack (most recent call first):
blt/cmake/BLTMacros.cmake:433 (blt_setup_target)
components/primal/src/CMakeLists.txt:39 (blt_add_library)

We are also passing for the openmp smoke test, which in turn tries to craft an mpiexe to launch the openmpi test. Which of course is wrong.

From blt_add_test

    # Handle mpi
    if ( ${arg_NUM_PROCS} )
        set(test_command ${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} ${arg_NUM_PROCS} ${test_command} )
    endif()

    add_test(NAME ${arg_NAME}
             COMMAND ${test_command} 
             )

If MPI isn't selected all at, you will see errors messages like the following:

    Start 5: blt_openmp_smoke
Could not find executable 2
Looked in the following places:
2
2
Release/2
Release/2
Debug/2
Debug/2
MinSizeRel/2
MinSizeRel/2
RelWithDebInfo/2
RelWithDebInfo/2
Deployment/2
Deployment/2
Development/2
Development/2
Unable to find executable: 2
5/5 Test #5: blt_openmp_smoke .................***Not Run   0.00 sec

BLT should provide a few cmake functions or macros to glean basic git information. For example, a Git the tag of a branch and/or the SHA1 at the tip of a branch.

The motivation for this is to provide the means for BLT-based projects to configure header files that consist of the Project's version, e.g., something like a "Version.h", or "configure.h"

For example, potential things client code would want to do include the following:

## gets the tag from the given branch, i.e., with git --describe
blt_git_tag( BRANCH <BRANCH> SOURCE_DIR <SOURCE_DIR> )

## gets the SHA1 hash at the tip of the given branch
blt_git_hash( BRANCH <BRANCH> SOURCE_DIR <SOURCE_DIR>  )

## get the name of the branch that is checked out
blt_git_branch( SOURCE_DIR <SOURCE_DIR> )

On some platforms, such as IBM's BG/Q, we need a way to specify that all tests should be run through the MPIEXEC command. This ensures that the tests are executed on a back-end node, rather than a front-end node.

Background

• Tests are added in our build system with the blt_add_test macro
• For MPI tests, we can set the number of ranks through a NUM_PROCS keyword.
• This invokes the test through ${MPIEXEC} using ${MPIEXEC_NUMPROC_FLAG} (e.g. srun -n2 ...)
• These two CMake variables are either provided in a host-config file, or are generated during CMake's find_package(MPI)

When testing blt, the "include" dir is never created, yet we add it to the target_includes.
gcc and clang don't seem to care, but gfortran issues a warning:

f951: Warning: Nonexistent include directory ‘blt_work/github/build-debug/include’ [-Wmissing-include-dirs]
[ 68%] Linking Fortran static library ../../../lib/libfruit.a

Here is where we set it:

# Defines the layout of the build directory. Namely,
# it indicates the location where the various header files should go,
# where to store libraries (static or shared), the location of the
# bin directory for all executables and the location for fortran modules.

# Set the path where all the headers will be stored
set(HEADER_INCLUDES_DIRECTORY
    ${PROJECT_BINARY_DIR}/include/
    CACHE PATH
    "Directory where all headers will go in the build tree"
    )
include_directories(${HEADER_INCLUDES_DIRECTORY})

This is happening b/c we have a bare bones project, but I think if folks aren't using copy_headers this could also happen. It's very unlikely that this will happen in user code that uses copy_headers.

Note: copy_headers is off by default.

gtest's death tests allows writing tests that verify that a program will exit under certain conditions, but they require forking and joining threads, and are not supported on all platforms. gtest gets around through the {ASSERT,EXPECT}_DEATH_IF_SUPPORTED macros, which are no-ops when death tests are not supported. They are controlled by the GTEST_HAS_DEATH_TEST compiler define.

Unfortunately, the code that determines whether death tests should be supported does not cover all platforms that we'd like to run code on, including IBM's BG/Q platform and the "Bash for Windows" environment. In addition, the platform setup code (in gtest's/include/gtest/internal/gtest-port.h) does not allow one to override this variable.

To resolve this, we need to add a simple patch to only redefine the GTEST_HAS_DEATH_TEST compiler define if it is not already defined.

Is there a special way to propagate defines? I am adding a library that depends on cuda, and nvcc is being invoked., but -D PARALLEL is not being passed to nvcc. Am I doing something incorrectly?

blt_add_library( NAME vtkh_par SOURCES ${vtkh_sources} ${vtkh_par_sources} HEADERS ${vtkh_par_headers} ${vtkh_headers} DEPENDS_ON ${vtkh_thirdparty_libs} mpi icet)

blt_add_target_compile_flags(TO vtkh_par FLAGS "-D PARALLEL")

I had a typo in the cmake vars passed as sources and headers, (so nothing was passed) and here is the current error message:

CMake Error at blt/cmake/BLTPrivateMacros.cmake:151 (target_link_libraries):
  INTERFACE library can only be used with the INTERFACE keyword of
  target_link_libraries
Call Stack (most recent call first):
  blt/cmake/BLTMacros.cmake:401 (blt_setup_target)

We should check if both headers and sources are empty, and if so let the poor soul who passed empty lists know what they have done.

• should be prefixed with blt_
• ${deps} is referenced but not set (should be an argument DEPENDS_ON)
• change sphinx_target_name to "NAME foo"

Fortran module installed in lib/fortran, which is specified with -qmoddir, but this is an output option. This also needs to be specified as an include directory using -I.

There should be a tag on master associated with the BLT version.

Also, why v0.1? I thought we were employing semantic versioning => MAJOR.MINOR.PATCH

add basic sphinx and doxygen projects to blt-test, to exercise our docs support

The COMMAND argument for the add test macro gets modified in a way that doesn't make sense (prepending the bin directory to it).

If the user has actually provided a test command they want to run, this will break.

I think we should have two arguments: EXECUTABLE and COMMAND, that can be joined together when calling CMake's add_test macro. This would allow the user to specify a custom command while also allowing us to find the full path of the executable.

It's crashing when cleaning up global objects:

6 0x00002aaaab1f1713 in __do_global_dtors_aux () from build-debug/lib/libgmock_main.so

this may be an issue with our smoke test, or an issue with gmock

Here are some (likely) related threads:

• https://groups.google.com/forum/#!topic/googlemock/5W-zJKZFtE0
• (this issue is refed from above thread: google/googlemock#54)
• google/googletest#461

Since it is easy for users of BLT to add their own compiler defines for OpenMP or MPI targets, we wanted to discuss not adding them via blt_register_lib for openmp and mpi.

Is there a reason you're not using the CMakeDependentOption CMake module for handling option dependencies?

i.e., ENABLE_GMOCK depends on ENABLE_GTEST, ENABLE_FRUIT depends on ENABLE_FORTRAN etc.

It would be easy to work up a PR to include this capability. CMake support goes as far back as at least 3.0 if not earlier.

Currently, executables and libraries that depend on CUDA will use nvcc for compilation. However, these targets could be compiled with clang's native CUDA support.

We need an option to differentiate between clang+cuda where clang is the host and nvcc is the CUDA compiler, and clang+cuda where clang is used for both.

We should define the minimum cmake version allowed for blt-based projects.

This minimum version should be tested/checked within blt, and should be clearly indicated in our documentation.

One of our core macros used for transitive dependencies is using a cmake 3.3 feature:

if(... IN_LIST ...)

This feature also requires setting cmake policy CMP0057 to NEW (as pointed out by @zbeekman in PR #108).

Note: Setting a value for CMP0057 is only valid in Cmake versions above 3.3 and is required in versions above 3.3.2 when using if(.. IN_LIST ...).

See: https://cmake.org/cmake/help/v3.3/policy/CMP0057.html

The following currently does not work:

blt_add_library(
    NAME                                      <mylib>
    HEADERS                                ${mylib_headers}
    HEADERS_OUTPUT_SUBDIR <mylib_dir>
    DEPENDS_ON                          <mylib_depends_on>
    )

blt_add_library requires a non-empty SOURCES parameter

The blt_custom_compiler_flag macro allows users to define an appropriate compiler-specific value for a compiler flag and currently allows setting different values for: gcc, clang, ibm, intel and msvc.

BLT determines the appropriate compiler based on the ${CMAKE_BUILD_TOOL} variable for msvc and on ${CMAKE_CXX_COMPILER_ID} for the other compilers, see cmake/SetupCompilerOptions.cmake

The current logic only supports the visual studio compiler on windows.
This ticket is a feature request to support the intel compiler on windows.

trying to debug some unit test issues and I was having a hard time finding output files

we should consider adding a WORKING_DIRECTORY arg to our blt_add_test()

I used the following directly:

add_test( NAME $
{arg_NAME}
COMMAND $
{test_command}
WORKING_DIRECTORY $
{runtime_output_directory}
)

and the output files showed up where I expected after make test (tests/)

When BLT is used by multiple projects (e.g. with a git submodule based project, where subprojects use BLT) it breaks. We should deal with this, perhaps with a BLT_LOADED variable, so that only the top-level BLT gets loaded.

There is an asymmetry in how we handle the EXTRA_C_FLAGS and EXTRA_CXX_FLAGS cache variables in SetupCompilerOptions.cmake. Here is the relevant part:

if(NOT CMAKE_CONFIGURATION_TYPES)
    ##########################################
    # Support Extra Flags for the C compiler.
    ##########################################
    if(EXTRA_C_FLAGS)
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${EXTRA_C_FLAGS}")  # <-- adds to CMAKE_C_FLAGS
    endif()
    ...

    #############################################
    # Support Extra Flags for the C++ compiler.
    #############################################
    if(EXTRA_CXX_FLAGS)
        add_compile_options("${EXTRA_CXX_FLAGS}")    # <-- directly sets these as compile options
    endif()
    ...

endif()

We should be consistent in how we apply these or note the reason for the inconsistency.

We should probably also provide and EXTRA_FORTRAN_FLAGS variable.

It would be nice if blt supported BUILD_SHARED_LIBS instead of requiring -DENABLE_SHARED_LIBS. Or perhaps, the default for ENABLE_SHARED_LIBS should come from BUILD_SHARED_LIBS instead of being false.

I am working on porting a project to blt, and on windows & I am getting a slew of dllimport errors.

With my prior cmake setup, to generate dllexport headers for shared libs to be used on windows, I relied on the fact that when building libname, -Dlibname_EXPORTS would be defined by cmake and passed to the compiler.

dllimport vs dllexport in this case will be triggered if this define doesn't exist.

This may have something to do with how blt names targets.

../../lib/libgtest.a(gtest-all.cc.o): In function `testing::internal::StreamingListener::SocketWriter::MakeConnection()':
gtest-all.cc:(.text+0x3af47): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[ 4%] Built target blt_gtest_smoke

I did not ask for -ffree-form to be added. This breaks my build. Either let the user control all compiler flags with your wonderful abstraction or at least detect from the file name (i.e. f77 ends in .f or .F). Letting users manage it would probably be better though. This is a deal breaker for us, unless there is a publicized API in BLT for removing compiler flags and/or setting defaults. The docs don't mention anything though.

Example:
C:\projects\conduit\src\blt\thirdparty_builtin\googletest-release-1.8.0\googletest\include\gtest/internal/gtest-internal.h(589): warning C4251: 'testing::internal::TypedTestCasePState::registered_tests_': class 'std::map<std::string,testing::internal::CodeLocation,std::less<_Kty>,std::allocator<std::pair<const _Kty,_Ty>>>' needs to have dll-interface to be used by clients of class

For more examples, see:
https://ci.appveyor.com/project/cyrush/conduit/build/1.0.643

I believe these didn't happen with gtest 1.7.

Seems like this issue:
google/googletest#860

This PR may provide a fix:
google/googletest#862

(But this PR hasn't been merged into gtest)

When you add a project using this style of project command:

project(project_name VERSION "x.y.z")

Our google test and google mock sub projects trigger the following warnings

CMake Warning (dev) at blt/thirdparty_builtin/googletest-release-1.8.0/CMakeLists.txt:3 (project):
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    PROJECT_VERSION
    PROJECT_VERSION_MAJOR
    PROJECT_VERSION_MINOR
    PROJECT_VERSION_PATCH
This warning is for project developers.  Use -Wno-dev to suppress it.

Issue reported by user, unable at this time to even try to verify. Please do so to make sure if this is happening to fix it.

there are a compelling cases for collapsing symbols from all TPLS and your lib into a single static lib to make it easy for consumers to link your app.

I believe Axom wants this, Alpine would use it as well.

Details still to be worked out.

The name should be updated to be only for uncrustify and the file suffix list needs to either be controllable outside of the function or greatly increased (missing .hxx, .cxx, .cc)

We have a small set of logic that supports the LLNL's Axom toolkit's "components" concept.

This is a bit special case, it should exist in Axom's CMake logic instead of BLT.