[question] Generate gitversions.h file for export() and local build individually?

[MartyMcFlyInTheSky]

What is your question?

I want to have git commit hash and tag information of the current build available in my source code. To do this I found this nice little tool that generates a cpp headerfile that I can include. However I run into problems regarding the different workflows of conan create . and conan build .

The issue is that as soon as the conan sources are copied to local cache it won't be a git repository anymore, so running the python script won't give me the results I needed (appart from the script not being available in the conan cache, not sure if that's a problem though..), so essentially I would have to export the versions.h file with it. Ok so I can generate it in the export() command. However, in a local build I also want to have this information available. So I would generate it in the build() method I suppose. But the problem is that the build() method is also called in conan local cache, so that doesn't work. Then I thought I could just check if the file exists and if not generate it in build() (it should be present in case it was previously copied by export/export_sources). But this has the problem that then I would only generate the versions.h file once, and since it's not tracked it wouldn't be overwritten in case i switch branches and thus alter my git hash. So that also doesn't work..

What is the suggested flow for this?

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[memsharded]

Hi @MartyMcFlyInTheSky

Thanks for your question.

Then I thought I could just check if the file exists and if not generate it in build() (it should be present in case it was previously copied by export/export_sources). But this has the problem that then I would only generate the versions.h file once, and since it's not tracked it wouldn't be overwritten in case i switch branches and thus alter my git hash. So that also doesn't work..

I am not sure if I understand this part. The versions.h is totally tied to the original source, and that also affects the Conan recipe-revision. Only if the source changes the version should change. And when the source changes, the export will generate a new recipe revision, so all should be good here.

I had a quick look to the repo you linked, and it sounds it might be a bit overkill, depending on the needs. If you use some tag convention, obtaining the version from there can probably be done easily with a couple of lines in the recipe.

[MartyMcFlyInTheSky]

Thanks again for your answer @memsharded . I think I forgot to mention I'm still on conan 1.61, so maybe the revision thing doesn't apply yet for us (wasn't it introduced in conan2?). The problem is that I'm not sure where to generate the version.h file. I need to do it before export in case of conan create . (so in the export() function) but if I want to use conan build . then I'm probably better of doing it in the build method? The library is indeed a bit overkill, but we're already using it and I didn't want to change too many things at once :()

[memsharded]

Revisions also exist in Conan 1.X, they have been there for several years now, (need to activate them in conf) and they are very recommended, if you haven't I'd strongly encourage to activate revisions and start using them as soon as possible.

The problem is that I'm not sure where to generate the version.h file. I need to do it before export in case of conan create . (so in the export() function) but if I want to use conan build . then I'm probably better of doing it in the build method?

Why before export? conan create does an export as first step, so it should work. About the build() method, sounds possible, but still need to be done conditionally, so it doesn't execute in the cache, because the version.h already exist, because otherwise it will fail.

[MartyMcFlyInTheSky]

Ah nice to know, so many conan1 features I didn't know about! In any case we're a bit hold back by gitlab at the moment since we're using this and they have yet to release their conan v2 endpoint, currently they don't support revisions yet.

The way I settled for now is to always generate version.h in export() but in build check if we have self.conan_data filled in, if not I assume we're in the repo folder and I will always generate the file from anew. This works quite well so far, however it still seems like a workaround. I'll close this as done.

[memsharded]

The way I settled for now is to always generate version.h in export() but in build check if we have self.conan_data filled in, if not I assume we're in the repo folder and I will always generate the file from anew. This works quite well so far, however it still seems like a workaround. I'll close this as done.

In Conan 1, the export() is called when calling conan source, so maybe you can leverage that?

[MartyMcFlyInTheSky]

Oh I just noticed that since I don't put anything into conandata, it will not detect correctly if I'm calling build from within user space or within the conan local cache, as in local cache I will also not have a conandata. Is there a better way to check if the build function is called from user space or local cache? Maybe for context, I'm building from withing the source repo usually using conan build ., but when I create the package using conan create . it will of course execute the build in the local cache. My workaround now is to walk up self.recipe_folder to see if the recipe resides withing .conan but this again is quite messy.

How did you mean that I could leverage the export() command?

[memsharded]

How did you mean that I could leverage the export() command?

Not the export() command, but the conan source . command. That command will call automatically the export() method. So it sounds like a good flow, no need to do anything special on the build() method or in the cache, the export() method can manage in both cases, at least for Conan 1.X (for Conan 2, conan source will not call export() method anymore).

In any case, I wouldn't check if it is a local build or not, I would check for the existence of the versions.h file.

[MartyMcFlyInTheSky]

Ah I think I understand. The idea is that I use always conan source . before conan build ., so regardless if it's a package creation or local flow I can generate the versions file in the export() method? Hmm I'll have to think about it. That's one extra command that anyone in the team has to remember. Might be fine though :+1:

[memsharded]

On the other hand, if this is going to be inconvenient for many devs (I don't know if the local flow is used by everybody or just a few devs, I kind of assumed it was just a full amount of devs not a whole team), then maybe it would be worth to try to avoid it.

I still think that checking the existence of the file in the build() would be good, no need for explicitly checking if it is a local build or not.