search

hroptatyr / yuck

Your Umbrella Command Kit, a bog-standard command line option parser for C with all the knickknackery and whatnots.
Other
61 stars 7 forks source link

Make git describe use unannotated tags #5

Closed ntessore closed 9 years ago

ntessore commented 9 years ago

Use git describe --tags so that scmver works with unannotated version tags coming from GitHub releases.

hroptatyr commented 9 years ago

Thanks!

ntessore commented 9 years ago

Thanks for merging this. Is there any info on how to make yuck "automatically determine (and make use of) version numbers in git controlled projects"? I get the correct version number with yuck scmver now, but using myprog --version still shows "unknown version".

hroptatyr commented 9 years ago

The idea was to write the version into a file which is consecutively used as a reference file. Then upon every make you'd call:

 yuck scmver --reference=FILE

And the file can then be used as a dependency for compiler/linker rules, along with:

yuck gen --version=`cat FILE` ...

This allows you to only rebuild the version bits if the version has actually changed. By default yuck assumes autotools (like its role model gengetopt) and uses PACKAGE_STRING, PACKAGE_VERSION or VERSION #defines (in that order).

But you've given me an idea, for very simple (Makefile only?) projects this might be overkill and indeed it would be better if yuck gen just incorporated the version as automatically determined. However, this is good for one-off builds only or if you throw in a make clean after every build or somehow build the yuck generated files upon every make(1) because once the files are generated the version number in there is hard-wired and nothing can actually change that.

I'm happy (and you're also welcome) to code up something along the lines of that but personally I won't have any use for this mode of operation.

ntessore commented 9 years ago

Thanks for the information!

I have indeed a "very simple Makefile only project", and had considered exactly what you described above. But thinking more about this, I can see that using a reference file is more suitable even for my simple case, if only because the version information would be available also when distributing the source outside of SCM (e.g. source tarballs). I will use what is currently available.