[CMake] cmake - node-gyp

[Stéphane Ancelot]

Hi,

I am trying to migrate an existing Makefile to cmake that is using node-gyp.


I have had a binding.gyp file that would need being generated with the 
libraries paths aqnd include paths. The problem is that I don't know how 
to do this.


The final binding.gyp file should look as follow :


# flags
# https://gyp.gsrc.io/docs/UserDocumentation.md

{

  "targets": [
    {
  "target_name": "control",
  "sources": [ "./control.cpp","./control_wrap.cpp" ],
  'defines': [
  'SWIG',
  '_GNU_SOURCE',
  '_REENTRANT',
  '__COBALT__'
    ],
  'libraries': [
    '../../IMPORT_EXPORT_UNIX/linux64/import_export_unix.o',
'../../mofilereader.0.1.2/linux64/libmofilereader.0.1.2.a',
  '../../MODULEDATA_UNIX/linux64/moduledata_unix.o',
  ' ../../EVENEMENTS_UNIX/linux64/evenements_unix.o'
    ],
  'ldflags': 
['-Wl,@/nfs/solaris/AFFAIRES_ECLIPSE/DEVELOPPEMENT/DEVELOPPEMENTS_RD/DEBIAN_64BITS/sancelot/KERNEL/TARGET/usr/xenomai-3.0-git/lib64/cobalt.wrappers 
-lalchemy -lcopperplate ',

'-L/nfs/solaris/AFFAIRES_ECLIPSE/DEVELOPPEMENT/DEVELOPPEMENTS_RD/DEBIAN_64BITS/sancelot/KERNEL/TARGET/usr/xenomai-3.0-git/lib64',
  '-lcobalt',
  '-lpthread',
  '-lrt'],
  'cflags!': [ '-fno-exceptions' ,'-fpermissive'],
  'cflags_cc!': [ '-fno-exceptions' ,'-fpermissive'],
   'include_dirs': [
'/nfs/solaris/AFFAIRES_ECLIPSE/DEVELOPPEMENT/DEVELOPPEMENTS_RD/DEBIAN_64BITS/sancelot/KERNEL/TARGET/usr/xenomai-3.0-git/include/cobalt',
'/nfs/solaris/AFFAIRES_ECLIPSE/DEVELOPPEMENT/DEVELOPPEMENTS_RD/DEBIAN_64BITS/sancelot/KERNEL/TARGET/usr/xenomai-3.0-git/include',
    '../INCLUDE_MACHINE',
    '../INCLUDE_COMMUN',
    '../EVENEMENTS_UNIX',
    '../IMPORT_EXPORT_UNIX',
    '../MODULEDATA_UNIX',
    '../LIBDEFAUT',
    '/usr/include/python2.7'
  ],
 }
    ],
}
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I compile and link modular code into a single DLL with MSVC?

[Jason Heeris]

On Wed, 27 Jun 2018 at 15:00, Innokentiy Alaytsev 
wrote:

> Do you create declspec declaration by hand? It may worth looking at the
> GenerateExportHeader
> 
>

Thanks, this will probably be very useful!


> Is it the code that you use in your CMake build script or just a
> representation of the general idea?
>

It's a representation, it's not in CMake at all currently, so anything's on
the table. However, it's not a far stretch from the real build steps.
Currently the build system is in another scripting language, which
traverses the dependencies from the top-level module, listing all
dependants recursively (no duplicates). It then compiles each one into an
.obj file and finally links all the .obj files together. Rather than
subject you to that, I've added a (very fragile) "build_manual.bat" file to
that Gitlab repo. But it contains those cl.exe and link.exe commands, and
produces a DLL with a single visible function, "module3()".

The fundamental problem here is simply one of scale. For my sample project,
adding common, module1, module2 to module3's dependencies isn't hard. But
when it's a couple of dozen dependencies, some of which may change from
time to time, with different degrees of indirectness, flattening them all
out would be very time consuming. As would finding and updating all parents
when sub-sub-module deps change. Tracking direct dependencies only is far
more manageable. Hope that makes sense.

Cheers,
Jason
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I compile and link modular code into a single DLL with MSVC?

[Innokentiy Alaytsev]

Hello!

First of all, a side note:


Jason Heeris wrote
> (Not shown: the macros to create the declspec declaration that MSVC needs
> to know what to export in the DLL. It's a type in moduleN and some
> functions in common.)

Do you create declspec declaration by hand? It may worth looking at the 
GenerateExportHeader
   CMake
module that provides the function generate_export_header(). If you need to
generate some additional macros you can use CUSTOM_CONTENT_FROM_VARIABLE
argument that is supported since CMake 3.7.

Now, let me clarify something:



Jason Heeris wrote
> This is already possible with existing build scripts, but these are
> becoming unmaintainable. The existing scripts compile each individual
> module into an .obj file and finally link them all into a DLL, as in:
> 
> cl.exe [args] common\common.c (creates common.obj)
> cl.exe [args] modules\module1\module1.c (creates module1.obj)
> ...
> cl.exe [args] modules\moduleN\ moduleN.c (creates moduleN.obj)
> 
> link.exe [args] common.obj module1.obj [...] moduleN.obj (creates
> moduleN.dll)

Is it the code that you use in your CMake build script or just a
representation of the general idea?

Best regards,
Innokentiy Alaytsev




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake fixup_bundle DESTDIR problem

[Randolph M. Fritz]

Under what circumstances does cmake place a fixup_bundle command in
dependencies.cmake? I've got a problem where fixup_bundle is being created
without reference to DESTDIR, and install fails when DESTDIR is used.

This is the generated dependencies.cmake file:

function(gp_item_default_embedded_path_override path)
  set(path "@executable_path" PARENT_SCOPE)
endfunction()

include(BundleUtilities)

set(plugins "")
list(APPEND plugins
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats/libqgif.dylib")
list(APPEND plugins
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats/libqico.dylib")
list(APPEND plugins
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats/libqjpeg.dylib")
list(APPEND plugins
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats/libqtiff.dylib")
list(APPEND plugins
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/plugins/platforms/libqcocoa.dylib")

fixup_bundle("${CMAKE_INSTALL_PREFIX}/bin/rvu" "${plugins}"
"/opt/local/libexec/qt5/lib;/opt/local/lib")



-- 
Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] weird linking breaks debugging?

[Victor Mataré]

Hi all,

On Linux, if I'm creating a lib and an executable:

add_library(something SHARED ${LIB_SRC})
add_executable(some-exec ${EXEC_SRC})
target_link_libraries(some-exec something)

Then the linker always links against libsomething.so instead of -lsomething.
For some reason this causes the shared object to be compiled into the the 
binary:

$ ldd some-exec 
linux-vdso.so.1 (0x7ffd1292b000)
libsomething.so (0x7fd9b346e000)
[...]

It's nice I can run the binary without setting LD_LIBRARY_PATH, but the 
debugger doesn't like it. When debugging some-exec, I can't autocomplete any 
symbols from the lib, and I can't set breakpoints there. If gdb somehow stops 
within a frame in libsomething, the symbols become available and I can debug 
normally.

In qt-creator it's even worse, there my breakpoints end up in all the wrong 
places and I can't get the program to stop inside the libsomething in a 
controlled manner.

So how do I tell cmake not to produce one huge mess of a binary? I've tried 
setting NO_SONAME to 1, but that doesn't change anything. Also, why doesn't 
cmake just use DT_RUNPATH=$ORIGIN?

Thanks, Victor


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] How can I compile and link modular code into a single DLL with MSVC?

[Jason Heeris]

This is a follow-on from "Linking object libraries into a Windows DLL in
3.12rc1"[1] - I figured since I'm reframing that question I should start a
new thread.

I have a project that has some common code and about a hundred modules. The
modules can have dependencies on each other (only ever as a directed
acyclic graph). What I want to do is, for any given module, compile it into
a single Windows DLL using MSVC (currently v19 under Visual Studio 2017).

This is already possible with existing build scripts, but these are
becoming unmaintainable. The existing scripts compile each individual
module into an .obj file and finally link them all into a DLL, as in:

cl.exe [args] common\common.c (creates common.obj)
cl.exe [args] modules\module1\module1.c (creates module1.obj)
...
cl.exe [args] modules\moduleN\ moduleN.c (creates moduleN.obj)

link.exe [args] common.obj module1.obj [...] moduleN.obj (creates
moduleN.dll)

(Not shown: the macros to create the declspec declaration that MSVC needs
to know what to export in the DLL. It's a type in moduleN and some
functions in common.)

I'm trying to figure out a way to do this with CMake that doesn't require
me to flatten out the entire dependency graph by hand. Each module has,
alongside it, a list of the other modules it *directly* depends on. These
are easy to put into a eg. target_link_libraries(...) call. But I can't
figure out how to get CMake to walk the whole dependency graph and pull
everything into the final link command.

Note that it doesn't have to be done with steps I describe above, if
there's another way to produce a single DLL I don't care how it happens.

What I've tried:

1. Making all the modules shared libs. This just produces a bunch of
separate DLLs for each module and common.

2. Chuck Atkins' post[2] suggesting separating usage requirements and
objects into different libraries. Since target objects don't propagate
using this method, it didn't help.

3. Now that 3.12rc1 is out, I tried using target_link_libraries() on the
object libraries themselves[1]. But as I found out from my previous post,
target objects don't
propagate this way either.

I'd appreciate any pointers. It seems like this is something that CMake is
designed to do, but I just can't figure out how. I have a very minimal
example (2 modules and common code) at https://gitlab.com/detly/cmake-dll-ex
which shows my attempt using object libraries, if that helps.

[1]
http://cmake.3232098.n2.nabble.com/Linking-object-libraries-into-a-Windows-DLL-in-3-12rc1-td7597756.html
[2]
http://cmake.3232098.n2.nabble.com/OBJECT-libraries-and-working-around-lake-of-target-link-libraries-tp7595795p7595830.html

Thanks,
Jason
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] race condition with target_objects

[Juan E. Sanchez]

Hello Brad,

Thanks for finding the issue.  I had simply replaced the shared library 
I was using with the name of the TARGET_OBJECTS generator.


The shared objects are great.  It helps me bypass Apple security issues 
when a system interpreter loads a shared library, which loads another 
shared library.


Regards,

Juan

On 6/26/18 1:34 PM, Brad King wrote:

On 06/26/2018 01:32 PM, Juan E. Sanchez wrote:

The likely problem is that the symdiff_objects and the symdiff_tcl are
in side-by-side directories.  They are both added using ADD_SUBDIRECTORY
one level up.  If I put symdiff_python before symdiff_tcl, then that
target will fail.  Please fix your Makefile generator.


Target dependencies are agnostic to the directories.  The ordering at
most matters for serial builds of independent targets.

While trying to reproduce this in a simple example I found the problem:

```
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})
```

That is not the way to reference an object library.

The documentation:

   
https://cmake.org/cmake/help/v3.12/manual/cmake-buildsystem.7.html#object-libraries

shows that `$` belongs in the list of *sources*,
not linked libraries.  You should be using:

```
add_library(symdiff_tcl SHARED ... $)
```

-Brad



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] race condition with target_objects

[Brad King]

On 06/26/2018 01:32 PM, Juan E. Sanchez wrote:
> The likely problem is that the symdiff_objects and the symdiff_tcl are 
> in side-by-side directories.  They are both added using ADD_SUBDIRECTORY 
> one level up.  If I put symdiff_python before symdiff_tcl, then that 
> target will fail.  Please fix your Makefile generator.

Target dependencies are agnostic to the directories.  The ordering at
most matters for serial builds of independent targets.

While trying to reproduce this in a simple example I found the problem:

```
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})
```

That is not the way to reference an object library.

The documentation:

  
https://cmake.org/cmake/help/v3.12/manual/cmake-buildsystem.7.html#object-libraries

shows that `$` belongs in the list of *sources*,
not linked libraries.  You should be using:

```
add_library(symdiff_tcl SHARED ... $)
```

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] race condition with target_objects

[Juan E. Sanchez]

Hi,

The likely problem is that the symdiff_objects and the symdiff_tcl are 
in side-by-side directories.  They are both added using ADD_SUBDIRECTORY 
one level up.  If I put symdiff_python before symdiff_tcl, then that 
target will fail.  Please fix your Makefile generator.


Regards,

Juan


On 6/26/18 10:58 AM, Brad King wrote:

On 06/25/2018 03:09 PM, Juan E. Sanchez wrote:

ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})

How do I tell cmake to wait?


Strange, our test suite covers that and the dependency appears.
The TARGET_OBJECTS generator expression evaluation has special
logic to forward the target-level dependency.


This is cmake 3.9.0-rc4


Please try a more recent version, perhaps an actual release.

-Brad



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Dos Line endings on response files when cross compiling.

[Brad King]

On 06/20/2018 10:42 AM, Gebhard, Joseph wrote:
> traced it down to dos line ending in the objects1.rsp file.  It was looking
> for a ctrl+M character on the end of the file name.
> After a little playing around with this we determined that 3.7.2 works fine,
> but 3.9, 3.10 and 3.11.3 all have this issue.
> 
> Is this a defect in cmake, or is there configuration I am missing in the 
> newer versions?

It's likely a regression.  Please open an issue:

  https://gitlab.kitware.com/cmake/cmake/issues

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] race condition with target_objects

[Brad King]

On 06/25/2018 03:09 PM, Juan E. Sanchez wrote:
> ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
> set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
> TARGET_LINK_LIBRARIES (symdiff_tcl $ 
> ${TCL_ARCHIVE})
> 
> How do I tell cmake to wait?

Strange, our test suite covers that and the dependency appears.
The TARGET_OBJECTS generator expression evaluation has special
logic to forward the target-level dependency.

> This is cmake 3.9.0-rc4

Please try a more recent version, perhaps an actual release.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking object libraries into a Windows DLL in 3.12rc1

[Jason Heeris]

On Tue, Jun 26, 2018 at 7:36 PM, Deniz Bahadir  
wrote:
Yes, you have overlooked an important detail. Only usage-requirements 
are transitive, the object-files are only propagated to directly 
dependent targets (not to indirectly dependent ones) *and only if 
they have a link/archive step*


Ah, for some reason I had thought object files formed part of the usage 
requirements of object libraries, but that's clearly not the case.


You need to explicitly add "module1" and "common" to the DLL's 
target_link_library call to get their object-files, too.


That's unfortunate (for me), but it is what it is I suppose. In my real 
project I have about 100 modules with dependencies on each other, and I 
was hoping CMake would take the work out of walking the dependency 
graph and constructing the final link command. Each module has its 
immediate dependencies listed, but not further than that. Resolving 
them all by hand and keeping them up to date isn't really feasible.


Thanks for the explanation!

- Jason



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking object libraries into a Windows DLL in 3.12rc1

[Deniz Bahadir]

Hi Jason,

Am 26.06.2018 um 07:45 schrieb Jason Heeris:



...

https://gitlab.com/snippets/1728169

Have I misunderstood how object library usage requirements and 
dependencies propagate? I would appreciate any pointers on this.


Yes, you have overlooked an important detail. Only usage-requirements 
are transitive, the object-files are only propagated to directly 
dependent targets (not to indirectly dependent ones) *and only if they 
have a link/archive step* (which object-files do not have). (See: 
https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries)


That means for your particular example:

With `target_link_libraries(module1 PUBLIC common)` your OBJECT library 
"module1" gets the usage-requirements of OBJECT library "common" but not 
its object-files.
The same applies to `target_link_libraries(module2 PUBLIC module1 
common)`: OBJECT library "module2" gets the usage-requirements of OBJECT 
libraries "module1" and "common" but not their object-files.
When linking the DLL with `target_link_libraries(module2_dll module2)` 
your DLL `module2_dll` gets all usage-requirements through "module2" 
(even indirect ones from "module1" and "common") but only the 
object-files of its direct dependency (which is "module2").


You need to explicitly add "module1" and "common" to the DLL's 
target_link_library call to get their object-files, too.


When creating a static library "module2_lib" your original approach 
worked, because linking/archiving a static library works different and 
includes all object-files, even indirect ones.


Currently, there is some debate about changing the behavior of OBJECT 
libraries:
https://gitlab.kitware.com/cmake/cmake/issues/18090 
https://gitlab.kitware.com/cmake/cmake/issues/17905



HTH,
Deniz Bahadir

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake