Fix relative paths

[konserw]

In case of cucumber-cpp project sometimes ${GCOV_SRC_PATH} is not an absolute path, for example:
^/include/cucumber-cpp/internal/drivers/GTestDriver.hpp
gmock/src/gmock/googletest/include/gtest/gtest.h
This fix is sufficient for cucumber-cpp, but I'm not sure if it covers all possible paths.

[JoakimSoderberg]

Hello,

Just so I understand you correctly. How I understand this:

The original code:

	#
	# /path/to/project/root/build/#path#to#project#root#subdir#the_file.c.gcov
	# ->
	# /path/to/project/root/subdir/the_file.c
	get_source_path_from_gcov_filename(GCOV_SRC_PATH ${GCOV_FILE})

So instead of something like this:

/path/to/project/root/build/#path#to#project#root#subdir#the_file.c.gcov

you get this?:

/path/to/project/root/build/^subdir#the_file.c.gcov
`` 

It would be nice to get an example of some exact output you're getting from your debug messages so I understand the problem exactly.

[JoakimSoderberg]

It was a long time since I looked at this code so I'm trying to refresh my mind a bit.

https://github.com/konserw/coveralls-cmake/blob/4849cfab90578818bdd1e34619c52b1dc323dea2/cmake/CoverallsGenerateGcov.cmake#L154-L174

#
# This macro converts from the full path format gcov outputs:
#
#    /path/to/project/root/build/#path#to#project#root#subdir#the_file.c.gcov
#
# to the original source file path the .gcov is for:
#
#   /path/to/project/root/subdir/the_file.c
#
macro(get_source_path_from_gcov_filename _SRC_FILENAME _GCOV_FILENAME)

	# /path/to/project/root/build/#path#to#project#root#subdir#the_file.c.gcov
	# ->
	# #path#to#project#root#subdir#the_file.c.gcov
	get_filename_component(_GCOV_FILENAME_WEXT ${_GCOV_FILENAME} NAME)

	# #path#to#project#root#subdir#the_file.c.gcov -> /path/to/project/root/subdir/the_file.c
	string(REGEX REPLACE "\\.gcov$" "" SRC_FILENAME_TMP ${_GCOV_FILENAME_WEXT})
	string(REGEX REPLACE "\#" "/" SRC_FILENAME_TMP ${SRC_FILENAME_TMP})
	set(${_SRC_FILENAME} "${SRC_FILENAME_TMP}")
endmacro()

Because I'm wondering it this would belong better in this macro maybe?

[JoakimSoderberg]

Can ve really rely on it always being .. here? Isn't this dependent on where you place your build folder?

For example. I mean the usual is to have it under project_root/build/ so then ../ would be project_root/ ... But what if the build folder is completly outside of the project_root does this still work then?

[konserw]

Can ve really rely on it always being .. here?

I'm not sure to be honest. I've got the ^ only as .. and only in front of path, for instance ^/include/cucumber-cpp/internal/drivers/GTestDriver.hpp is in fact ../include/cucumber-cpp/internal/drivers/GTestDriver.hpp

I mean the usual is to have it under project_root/build/

And this is also my case

. But what if the build folder is completly outside of the project_root does this still work then

Haven't checked

Because I'm wondering it this would belong better in this macro maybe?

Yes - later on I've moved it to that macro, just forgot to update this branch also

[JoakimSoderberg]

Forgot to thank you for the patch, just want to understand the issue before I merge so nothing gets broken :)

[konserw]

Now I've pushed most of my changes. Let me know if you want it all.

[JoakimSoderberg]

@konserw ok, good that you pushed the latest.

It would be nice with your exact debug output so I can see exactly what you are getting when you are building.

And maybe the version of gcov that is producing this form? So that I can test myself with the same project, and can test a few scenarios if this breaks or not (for example using a non-standard build dir as I mentioned)