Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

So. Where is "gitrevision.h"? #198

Closed
squidfarts opened this issue Jul 22, 2019 · 8 comments
Closed

So. Where is "gitrevision.h"? #198

squidfarts opened this issue Jul 22, 2019 · 8 comments
Labels

Comments

@squidfarts
Copy link

squidfarts commented Jul 22, 2019

Hello there.

I was writing Meson support for your testing framework when I bumped into my first issue. If you can tell me where "gitrevision.h" can be located and why it was not included that would nice.

2019-07-21_18-59-11

@thoni56
Copy link
Contributor

thoni56 commented Jul 23, 2019

Thanks for looking to support Cgreen!

gitrevision.h is generated automatically by CMake. The instructions for that is in src/CMakeList.txt.

As you may have noticed the build system is CMake with an optional thin layer of make on top.

There might be a few other issues if you are trying to mimic the complete build system. But, please get back to this issue when that happens ;-)

If this is going to be an on-going story, perhaps we should change the title of this issue?

@intmainreturnzero
Copy link

The problem is that when CGreen is not a git repository (e.g. when a release tarball is downloaded and extracted), generated makefile at location build/src/CMakeFiles/cgreen_shared.dir/depend.make doesn't contain the following entry:

src/CMakeFiles/cgreen_shared.dir/utils.c.o: ../gitrevision.h

and hence even the make rule for generating gitrevision.h is present, it is not executed. I am not experienced with writing cmake rules, so if someone fixes it, it would be really great!

@thoni56
Copy link
Contributor

thoni56 commented Aug 7, 2019

Good point. One option would be to check for .git and if not found make something sensible.

Don't see how we could generate correct git revision from a tar-ball so it'll have to be something like unknown revision or even empty.

I'll have a look at that. In the mean time you could create one manually to avoid the problem for now.

@squidfarts
Copy link
Author

Thanks. 😊

@intmainreturnzero
Copy link

I am thinking that in case of a release tarball, we should parse the path with some regex using awk etc. to extract out the version number after 'cgreen-' and put that in gitrevision.h. However, the bigger problem (which I am not able to debug) is that the make rule doesn't get executed due to the missing dependency in makefile pointed above, so creating the make rule doesn't help.

Could you please point to the cmake part that generates rules for utils.c?

@thoni56
Copy link
Contributor

thoni56 commented Aug 8, 2019

The CMake rules/code that generates gitrevision.h is the first lines in src/CMakeLists.txt.

Basically it asks git about the necessary information and pipes that into the file.

There is actually an else branch there that explicitly says "when the software is built from a source tarball", so it should actually generate the file under those circumstances also.

I'll have to look into why that doesn't happen.

@thoni56
Copy link
Contributor

thoni56 commented Aug 8, 2019

Turns out that there is one single word missing from src/CMakeList.txt: VERBATIM.

CMake has many quirks, this is definitely one.

Change

  add_custom_command(OUTPUT ${CMAKE_SOURCE_DIR}/gitrevision.h
      COMMAND ${CMAKE_COMMAND} -E echo "#define GITREVISION \"unknown\"" > ${CMAKE_SOURCE_DIR}/gitrevision.h
)

to

  add_custom_command(OUTPUT ${CMAKE_SOURCE_DIR}/gitrevision.h
      COMMAND ${CMAKE_COMMAND} -E echo "#define GITREVISION \"unknown\"" > ${CMAKE_SOURCE_DIR}/gitrevision.h
      VERBATIM
)

I.e add the VERBATIM word as the last argument to add_custom_command.

I'll commit this and force the 1.2.0 release to include it.

@thoni56 thoni56 closed this as completed in a8cd723 Aug 8, 2019
@thoni56 thoni56 added the bug label Aug 8, 2019
@thoni56
Copy link
Contributor

thoni56 commented Aug 8, 2019

Please check that this works in your environment.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants