apitrace-3.0 fails to compile due to missing #include <string.h>

[ssuominengentoo]

Original bug report was filed here, http://bugs.gentoo.org/465504

libpng 1.6's png.h no longer has include for string.h, and because common/image_png.cpp is using memcpy() function, it should include string.h by itself, and not rely on it being
pulled in by png.h

the errors look like this:

/var/tmp/portage/dev-util/apitrace-3.0-r1/work/apitrace-3.0/common/image_png.cpp: In function ‘void image::pngWriteCallback(png_structp, png_bytep, png_size_t)’:
/var/tmp/portage/dev-util/apitrace-3.0-r1/work/apitrace-3.0/common/image_png.cpp:222:49: error: ‘memcpy’ was not declared in this scope
memcpy(buf->buffer + buf->size, data, length);
^
make[2]: *** [CMakeFiles/common.dir/common/image_png.cpp.o] Error 1

[ssuominengentoo]

The memcpy.patch can be found here:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/apitrace/files/

[ssuominengentoo]

Simple as including string.h after stdlib.h in common/image_png.cpp

[jrfonseca]

Thanks for the report.

I tried to apply, but just noticed that that memcpy call no longer exists on the HEAD.

Note that I don't plan to maintain stable branches and only do version bumps when there are new noteworthy features, so I'd recommend for Gentoo to eventually switch to the tip.

[vapier]

i don't think pulling from git master makes sense

[jrfonseca]

The problem is that I don't make official releases that often, or maintain stable branches.

Anyway, it was too long since the last release, so I made a new one: https://github.com/apitrace/apitrace/tags

[vapier]

when you're using git, "creating a release" is trivial. git tag 5.0 && git push --tags. it's not like you have to generate tarballs or something.

[jrfonseca]

I'm not sure what you desire anymore.

Indeed it is so easy to make a release, that I could have a script that would tag every master commit with a sequential number. Would that make you happier? Is that any better from using a commit hash?

What is a "release" for you anyway? This is a developer tool under active development, so for me a "release" is a vehicle to announce major new features, and not a commitment for something stabler. In truth, soon after a release is done, master tends to be stabler (that is fewer bugs) than the last release.

Maybe I should just stop releases and tags altogether. Then people had no choice to use master and hash commits. I could still announce cool new features without resorting to version numbers.

[vapier]

a release is a tag of a source repo at a state that is expected/known to be good. expecting downstream distros to randomly pick a git revision and hope for the best is unreasonable.

all we desire is that from time to time you tag a new rev that you expect to be good.

[jrfonseca]

Yes, a unlucky pick could yield unstable results. Fair enough.

BTW, the new 4.0 tag is expected to be good, and was not a random pick. There haven't been invasive new features/changes lately -- just bug fixes -- so everything should be stable.

[vapier]

thanks, that sounds great for us. we'll update Gentoo soon.