Re: [CMake] Testing an exe with gtest - possible?

[cen]

Thanks, this pointed me in the right direction.

I ended up moving main() to it's own file so nothing depends on it, 
using a static add_library (project sources minus the main.cpp) and 
depend on that target from gtest exe project. Works like a charm.



I missed the discourse announcement, I'll use it in the future.


Best regards, cen


On 11/20/19 3:16 PM, Kyle Edwards wrote:

On Wed, 2019-11-20 at 00:54 +0100, cen wrote:

Hi

I have an existing c++ exe project which I want to test with gtest.
I
have not yet found an easy way to keep the project as is and test it
directly since gtest insists (obviously) to link against the code
being
tested. I found a smart answer on SO to link against object files
and
that works ok but it's messy and a lot of manual setup after cmake
project generation, probably impossible to automate in cmake.

The other quick way is to change the VS project output to a static
lib.
That also works but is a manual step which again not sure can be
automated at all. And there is a bigger issue hidden in here.. I
can't
link to this lib due to dual main() entry point.

So unless there is some smart workaround to keep project as an exe
and
get gtest to work, I guess the only remaining option is to separate
the
main() into a small bootstrap exe and then link against the rest of
the
program (which contains the actual testable logic) as a lib. Finally,
if
I understand correctly, using target_link_libraries will
automatically
set up the two projects as dependent and lib will always get built
before the main is run.

Check out the $ generator expression. This will let
you link directly against the object files built for the executable.

This mailing list is deprecated. Please post further discussion to
Discourse:

https://discourse.cmake.org/c/code

Kyle

--

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Missing dll on program startup - a way automate it?

[cen]

Thanks, this is exactly what I need.

Unfortunately constructing the path expansion involves some gymnastics. 
If Find* exposes a list of directories it's just a simple list join (-> 
boost) but if it does not it is more involved..


list(JOIN Boost_LIBRARY_DIRS ";" BOOST_PATH)

set(ZLIB_PATH "")
FOREACH(LIB_NAME ${ZLIB_LIBRARIES})
   get_filename_component(LDIR ${LIB_NAME} DIRECTORY)
   if (NOT ZLIB_PATH MATCHES "${LDIR}")
 set(ZLIB_PATH "${ZLIB_PATH};${LDIR}")
   endif()
ENDFOREACH()

set(EXPAND_PATH "${ZLIB_PATH};${BOOST_PATH}")
set_target_properties(${PROJECT_NAME} PROPERTIES VS_DEBUGGER_ENVIRONMENT 
"PATH=%PATH%${EXPAND_PATH}")



Is there a way to get a list of all additional library directories? That 
would be ideal but I couldn't find anything.



On 11/20/19 9:32 AM, Petr Kmoch wrote:

Hi.

I haven't used it yet, but I believe the target property 
https://cmake.org/cmake/help/latest/prop_tgt/VS_DEBUGGER_ENVIRONMENT.html 
might help you.


Petr

On Wed, 20 Nov 2019 at 01:02, cen <mailto:imba...@gmail.com>> wrote:


Hi

Perhaps not really a cmake problem but here we go. An exe depends
on a
few DLLs which I ship in the repo so the rest of the devs don't
have to
build them or fetch them somewhere else. Cmake finds the libraries
and
project builds just fine, until you run it from VS.. you are
welcomed by
the "missing dll" windows error. So I have to copy all the dlls to
the
build/run folder to make it work but this is a manual step. Is there
some way in cmake/VS to somehow tell the IDE to append the execution
$PATH with all the specified library dependencies or something along
those lines? Ideally my goal is to just run cmake, open VS, build the
project and run, all automagical.

I would prefer to keep the dynamic linking.


Best regards, cen

-- 


Powered by kitware.com/cmake <http://kitware.com/cmake>

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

Visit other Kitware open-source projects at
https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of
https://discourse.cmake.org

-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Missing dll on program startup - a way automate it?

[cen]

Hi

Perhaps not really a cmake problem but here we go. An exe depends on a 
few DLLs which I ship in the repo so the rest of the devs don't have to 
build them or fetch them somewhere else. Cmake finds the libraries and 
project builds just fine, until you run it from VS.. you are welcomed by 
the "missing dll" windows error. So I have to copy all the dlls to the 
build/run folder to make it work but this is a manual step. Is there 
some way in cmake/VS to somehow tell the IDE to append the execution 
$PATH with all the specified library dependencies or something along 
those lines? Ideally my goal is to just run cmake, open VS, build the 
project and run, all automagical.


I would prefer to keep the dynamic linking.


Best regards, cen

--

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Testing an exe with gtest - possible?

[cen]

Hi

I have an existing c++ exe project which I want to test with gtest. I 
have not yet found an easy way to keep the project as is and test it 
directly since gtest insists (obviously) to link against the code being 
tested. I found a smart answer on SO to link against object files and 
that works ok but it's messy and a lot of manual setup after cmake 
project generation, probably impossible to automate in cmake.


The other quick way is to change the VS project output to a static lib. 
That also works but is a manual step which again not sure can be 
automated at all. And there is a bigger issue hidden in here.. I can't 
link to this lib due to dual main() entry point.


So unless there is some smart workaround to keep project as an exe and 
get gtest to work, I guess the only remaining option is to separate the 
main() into a small bootstrap exe and then link against the rest of the 
program (which contains the actual testable logic) as a lib. Finally, if 
I understand correctly, using target_link_libraries will automatically 
set up the two projects as dependent and lib will always get built 
before the main is run.



Hopefully not inventing hot water in 2019 here.


Best regards, cen

--

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] GTest confusion - linking to project being tested

[cen]

Hi

I am essentially trying to solve this problem: 
https://stackoverflow.com/questions/19886397/how-to-solve-the-error-lnk2019-unresolved-external-symbol-function/30667584#30667584


and I have hit a wall.

Using CMake to generate solution with two VC projects, one is a 
monolithic .exe the other is a gtest project meant to test a few 
functions from the exe.


I am having a problem linking to main project in gtest project because:

1. The project being tested is an exe, not a lib.

2. Ideally I don't want to have all h/cpp files pulled up in the gtest 
project, only have the actual test files in there.


3. Adding the main project as a reference to gtest project didn't help 
(suggestion from SO thread).


4. Manually adding main project .obj files in gtest as linker input 
solves the problem and is essentially the solution I would like to 
achieve with CMake.


5. I hit another unpleasant snafu after #4 because main and gtest 
project implement a main() method and this fails to build. But I guess 
this can be avoided by renaming


the gtest main and changing the entry point of the gtest project.


So if 5 is solvable, what I really need is a CMake solution to #4.. to 
automatically build the tested project and link to it's object files in 
gtest project.



This seems to me to be a really obvious case for testing so I am not 
sure whether it really is that complicated or I am doing things wrong.



Bets regards, cen

--

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] Effective CMake - warning on bad practices

[cen]

I finished watching "Effective CMake" talk by Daniel Pfeifer from last 
year and it seems to me it is the "GO TO" resource for best practices. A 
quick scan of my CMakeLists.txt files and sure enough, I use 
include_directories() and other "dont's". The problem is that none of 
the things mentioned in the talk:


a) give any warnings when running cmake

b) are mentioned as bad practice in the docs


What I would prefer is that everytime a bad practice is used a big red 
warning would be printed by CMake so I could see it and correct it.


Since CMake is apparently very slow deprecating things a solution 
appeared in my mind after seeing the function wrap functionality. How 
about a file called Effective.cmake which contains something like 
(pseudocode):


function(include_directories input output)

    message(DEPRECATION "Use target_include_directories() instead."

    _include_directories(...)

endfunction()

function(set input output)

    if (${ARG0} STREQUAL "CMAKE_CXX_FLAGS")

        message(DEPRECATION "You probably shouldn't use this directly")

    endif

    _set(...)

endfunction()

...


then include(Effective.cmake) in your CMakeLists.txt to enable all 
warnings. The effort here is to compile a list of existing bad practices 
and wrap them (if such a thing is possible).



Does this approach seem reasonable? Is there an effort with similar 
goals out in the wild which I should know about?




Best regards,

cen




--

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] Proper way to support 64bit and 32bit builds

[cen]

I tried setting CXXFLAGS and CMAKE_CXX_FLAGS to -m32 before the 
project() call but nothing changed. I could make it fail with 
"CXXFLAGS=-m32 cmake -G ..." from command line but this seems wrong. A 
minimal CMakeLists.txt example would be nice.



Hendrik Sattler je 29. 10. 2016 ob 15:25 napisal:

You need to set these compiler flags BEFORE the project() call to let CMake 
detect all stuff properly. There is a CMake  variable telling you the size of a 
void*.


Am 29. Oktober 2016 12:22:07 MESZ, schrieb cen <imba...@gmail.com>:

Hi

Once I switch to 32bit builds, CMake fails to recognise that
glibc-devel.i686 is not installed resulting in an error when running
make.
In the same way, my own FindGMP fails to recognize that gmp-devel.i686
is not installed. I need CMake to fail if these things are missing.
At least for the compiler part, I'm pretty sure I am missing some var
or
flag to tell CMake I expect a 32 bit build.

This is what I use to switch between builds in CMakeLists.txt (ARCH var

is irrelevant here,  I use it later on for CPack):

if (BUILD_32)
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
"-m32" LINK_FLAGS "-m32")
 MESSAGE(STATUS "Excluding 64bit library paths from search.")
 set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
 set(ARCH i686)
elseif (BUILD_64)
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS
"-m64" LINK_FLAGS "-m64")
 set(ARCH amd64)
else()
 set(ARCH amd64)
endif()


For the FindGMP module, I am not really sure what the best practice
is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I

explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake
be smarter than this?


--

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Proper way to support 64bit and 32bit builds

[cen]

Hi

Once I switch to 32bit builds, CMake fails to recognise that 
glibc-devel.i686 is not installed resulting in an error when running make.
In the same way, my own FindGMP fails to recognize that gmp-devel.i686 
is not installed. I need CMake to fail if these things are missing.
At least for the compiler part, I'm pretty sure I am missing some var or 
flag to tell CMake I expect a 32 bit build.


This is what I use to switch between builds in CMakeLists.txt (ARCH var 
is irrelevant here,  I use it later on for CPack):


if (BUILD_32)
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
"-m32" LINK_FLAGS "-m32")

MESSAGE(STATUS "Excluding 64bit library paths from search.")
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
set(ARCH i686)
elseif (BUILD_64)
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
"-m64" LINK_FLAGS "-m64")

set(ARCH amd64)
else()
set(ARCH amd64)
endif()


For the FindGMP module, I am not really sure what the best practice 
is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I 
explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake 
be smarter than this?

--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CPack DEB version info is missing patch level

[cen]

Sorry for wasting your time, it does work indeed. I forgot to pull the 
correct version of CmakeLists.txt on my debian machine..


Thank you.


Domen Vrankar je 25. 10. 2016 ob 21:48 napisal:
2016-10-25 16:59 GMT+02:00 cen <imba...@gmail.com 
<mailto:imba...@gmail.com>>:



Why is patch level not baked into the DEB but it is in RPM? If
install the deb, soft links have the proper patch level version so
I guess it is ultimately ok but kinda annoying.


Which version of CPack are you using?

I can't reproduce this even with old CMake version 3.0.2 and minimal 
CMakeLists.txt:


#--

cmake_minimum_required(VERSION 3.0)
project(test)

install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/CMakeLists.txt
DESTINATION dest)

set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 2)
set(CPACK_PACKAGE_VERSION_PATCH 3)
set(CPACK_PACKAGE_CONTACT "Test <t...@test.com <mailto:t...@test.com>>")

include(CPack)

#--

cmake -D CPACK_BINARY_DEB:bool=ON ..
make package
dpkg-deb -I test-1.2.3-Linux.deb

result: Version: 1.2.3


Regards,
Domen


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CPack DEB version info is missing patch level

[cen]

Hi

I am not sure if this is a CPack thing or a deb thing.

my CmakeLists.txt:

SET(VERSION_MAJOR "1")
SET(VERSION_MINOR "3")
SET(VERSION_PATCH "2")

SET(CPACK_PACKAGE_VERSION_MAJOR "${VERSION_MAJOR}")
SET(CPACK_PACKAGE_VERSION_MINOR "${VERSION_MINOR}")
SET(CPACK_PACKAGE_VERSION_PATCH "${VERSION_PATCH}")


Produced RPM, running rpm -qip my.rpm results in:

Version : 1.3.2


Produced DEB, running dpkg-deb -I my.deb results in:

Version: 1.3


Why is patch level not baked into the DEB but it is in RPM? If install 
the deb, soft links have the proper patch level version so I guess it is 
ultimately ok but kinda annoying.



Best regards, cen


--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CPack source package install location

[cen]

Exactly on point, thank you.

Domen Vrankar je 04. 07. 2016 ob 08:44 napisal:

Hi,


I have a very standard CPack configuration for deb package. I have two
questions:

1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB"

This is supposedly a binary package but when I install it on the machine I
see header files being installed in /usr/include.

Is this normal?

I'm guessing that CPackConfig.cmake is generated by cmake and not hand written.

CMake generates CPackConfig.cmake that can be used to create a package
with content listed with 'install()' commands (see:
https://cmake.org/cmake/help/v3.5/command/install.html). If those
commands contain header files then those files will be part of the
package. You could also split packages between bin and dev packages by
using COMPONENT attribute in install commands and then generating
component packages - one per component.


2. Header files are installed into /usr/include but there is one problem:
other projects using the library are including header files with #include
 as a standard practice.

So I actually want them installed in /usr/include/libname instead. After
scouring the CPack variables in documentation I didn't really find anything
suitable to do this. Is it possible to achieve?

This would have to be changed in CMakeLists.txt (install commands) or
is possibly already written with prefix variable in mind in which case
you have to look into CMakeLists.txt install commands and set the
variable that is used there for this purpose.

Regards,
Domen


--

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CPack source package install location

[cen]

Hi

I have a very standard CPack configuration for deb package. I have two 
questions:


1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB"

This is supposedly a binary package but when I install it on the machine 
I see header files being installed in /usr/include.


Is this normal?


2. Header files are installed into /usr/include but there is one 
problem: other projects using the library are including header files 
with #include  as a standard practice.


So I actually want them installed in /usr/include/libname instead. After 
scouring the CPack variables in documentation I didn't really find 
anything suitable to do this. Is it possible to achieve?||

||



-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Documenting the -H and -B options

[cen]

Funny you say that, -H and -B options are the only ones I actually use
all the time. I never really understood why these are not documented or
part of the man page. Is there an official reasoning behind this?

On 3. 04. 2016 10:49, Craig Scott wrote:
> It would seem that the undocumented -H and -B options of cmake are
> fairly well known and it is likely they are being widely used by now. Is
> there any reason they cannot become officially documented options? A
> quick bit of googling and searching on StackOverflow suggests they
> perhaps ought to graduate to formally supported options.
> 
> -- 
> Craig Scott
> Melbourne, Australia
> http://crascit.com
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake