kspalaiologos / bzip3

I think noone ever used this library before to see the problem with VERSION (string) constant @ `libbz3.c:473'.
I tried to use it as a plugin and stumbled on this thing right at the start:

$ cc  -O3 -I./bzip3/include -c -o bzip3/src/libbz3.o
bzip3/src/libbz3.c: In function ‘bz3_version’:
bzip3/src/libbz3.c:473:51: error: ‘VERSION’ undeclared (first use in this function)
 BZIP3_API const char * bz3_version(void) { return VERSION; }
                                                   ^~~~~~~
bzip3/src/libbz3.c:473:51: note: each undeclared identifier is reported only once for each function it appears in
make: *** [bzip3/src/libbz3.o] Error 1

It should be defined in library, so everyone wanting to use it on its own, as a plugin for example, was able to do that. It would also identify the version within library so a user would know it from the beginning.
You should consider to change the name of that constant because I, for example, in my app, already had a local version string, called, you guessed that - "VERSION". Now imagine what happened when I tried to do that:

$ cc -g -Ibzip3/include -DVERSION="\"1.3.2\"" -c -o main1.o main1.c
<command-line>:0:9: error: expected identifier or ‘(’ before string constant
main1.c:16:7: note: in expansion of macro ‘VERSION’
 char* VERSION = "v0.1";
       ^~~~~~~
make: *** [main1.o] Error 1

These names immediately clashed, preventing compilation.

Again, "VERSION" is common name for version string, even more common than "WINDOWS", so you would be better with something like "BZ3VERSION" "LIBBZ3_VERSION".

I think noone ever used this library before to see the problem with VERSION (string) constant @ `libbz3.c:473'.

I think that someone has not tried to use the bundled scripts and is extrapolating things based on their own guess of how it works :-). The build script defines VERSION and obtains it from here:

bzip3/build-aux/git-version-gen

Line 212 in bb2ced7

echo "$v" | tr -d "$nl"

It should be defined in library, so everyone wanting to use it on its own, as a plugin for example, was able to do that. It would also identify the version within library so a user would know it from the beginning.

Consider using the configure script attached. It will build a .a file for you (a "statically linked library", or just a POSIX archive of object files) which you can pass to the linker as a library to link against. You should also add the include path to the compiler's flags. Or just use libtool and pkg-config for what it was intended to be used!

$ cc `pkg-config --cflags --libs bzip3` -o my_app_that_uses_bz3 source.c

Anyway...

You should consider to change the name of that constant because I, for example, in my app, already had a local version string, called, you guessed that - "VERSION". Now imagine what happened when I tried to do that:

This is another reason for why you shouldn't ignore all instructions and files present in the repo and try to guess how you are supposed to use the build system. Notice that the value of the defined macro VERSION is used only in private headers and source code of bzip3, not in the public include header. Meaning, you could compile bzip3 with the proper for bzip3 VERSION define, and then supply a different define for the VERSION of some other code that you wrote. Or just use the darn build system (either autotools or cmake) :-).

I think that someone has not tried to use the bundled scripts and is extrapolating things based on their own guess of how it works :-)

I didn't, true, because they don't work. This automake is and always was magical, so I use my own Makefile. Simple and effective.

And yes, I did expect it to work add drop in, like libdeflate, which works without any scripts, by compiling all files.
That's what I expected.

And, I can't use aitotools, nor cmake in my application. It doesn't work this way. It's not feasible.

Therefore I stand by my opinion about this name.

This automake is and always was magical, so I use my own Makefile. Simple and effective.

Uh huh. So effective you are here reporting something you are not even using as broken because your own re-implementation is incomplete.

If you must use your own build system just inject the variable yourself. The tarball has pre-generated version info embeded in the archivo and if you are Git cloning there is a script to figure it out.

Aha, it's getting started.
You can be snappy all you want but you do exactly the same thing - inject the variable yourself.

libtool: compile:  gcc -DPACKAGE_NAME=\"bzip3\" -DPACKAGE_TARNAME=\"bzip3\" -DPACKAGE_VERSION=\"1.3.2\" 
"-DPACKAGE_STRING=\"bzip3 1.3.2\"" -DPACKAGE_BUGREPORT=\"https://github.com/kspalaiologos/bzip3\" -DPACKAGE_URL=\"\"
 -DPACKAGE=\"bzip3\" -DVERSION=\"1.3.2\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_GETOPT_H=1 -DHAVE_GETOPT_LONG=1 -Drestrict=__restrict__ -I. -I./include -g -O2 -pthread -DPTHREAD 
-O2 -g3 -fPIC -march=native -mtune=native -MT src/libbz3.lo -MD -MP -MF src/.deps/libbz3.Tpo -c src/libbz3.c  -fPIC -DPIC -o src/.libs/libbz3.o

If you don't see that I will magnify it.

 -DVERSION=\"1.3.2\"

Now, I explained my point. Explained also, that in environment I have at one's disposal there is no way to do autotools' nor cmake's equilibristics.
I explain users point of view, you take it as attack. Attack on what?

From my perspective, the average user installs bzip3 from the system's package repositories and then uses the -dev package if they need the library or header. In general, vendoring a library unless you have to puts you in a spot where you have to continuously update it instead of just relying on whatever the target OS has and most distro maintainers will not let you do that unless you have a very good reason to.
I am sorry, but the software is meant to be built with the scripts that we supply. If you want to stray from these recommendations, you are essentially on your own. There are many popular projects that use exclusively autotools and are very difficult to build using a regular retrofitted Makefile (primarily GNU code). Anyway, if you specifically have any questions about our build system that would help you develop your own solution, I am glad to answer them.

'VERSION' of library