search

adobe / XMP-Toolkit-SDK

The XMP Toolkit allows you to integrate XMP functionality into your product or solution
BSD 3-Clause "New" or "Revised" License
205 stars 83 forks source link

Use submodules to handle dependencies | Fix your library! #56

Open LorenDB opened 2 years ago

LorenDB commented 2 years ago

In #52, I found that I needed to install third-party sources in order to get the build working. However, I don't like the method of having to download sources manually. I strongly encourage moving to git submodules to manage these dependencies. This would simplify the dependency fetching process immensely: simply run git clone https://github.com/adobe/XMP-Toolkit-SDK.git --recurse-submodules, and presto, dependencies are downloaded! In addition, running git submodule update would keep dependencies up-to-date.

Furthermore, there is really no excuse to not do so, since both manually-fetched dependencies are available through git: zlib (or zlib-ng, for that matter) and libexpat.

RANT ALERT

If I am coming across as a bit harsh, I apologize, but this library is really not fun to work with. Most libraries I encounter have simple buildsystems (e.g. mkdir build; cd build; cmake ..; cmake --build .) that rely on system-bundled dependencies where possible (e.g. use CMake's find_package). In contrast, this library uses a strange conglomeration of make and CMake, requires manual download and placement of third-party dependency sources, and then, when I try to build (using make for simplicity instead of trying to wrap my head around a lot of different targets), fails with a linker error about not being able to locate libssp.a. Sure, a failure to find a library isn't that terrible, but I can't turn up a lot of information online. After grepping through the build directory, I found something terrifying.

Somebody hardcoded the path to compiler libs on Linux without bothering to verify that (a) the GCC dir is going to exist at /user/unicore/i80386linux_x64/compiler (it doesn't; probably no modern Linux distro even has /user), (b) the user has GCC 4.8.2 (they won't, given the fact that GCC is all the way to 11.2), (c) the user is using Linux kernel 3.10 (I sincerely hope they are not), (d) the user is on a 64-bit platform (most users are, but a few might be running code on legacy machines), or (e) the user is even using GCC (some people do use clang at times, myself among them).

Given all this, my level of enthusiasm for using this library is very low. Why use a library that is going to be a pain to work with?

END RANT

Sorry to disturb you with this rant. Have a nice day! 🙃

CZDanol commented 2 years ago

I feel the same, just trying to make it work today :( This thing is a mess.

LorenDB commented 2 years ago

And well over a month (EDIT 5/11/2023: well over one year) later, the main issue hasn't even been addressed by the maintainers. At this point, I have no intentions of even trying to make use of this library. I'll leave the issue open as it is relevant on various points, but as far as I'm concerned, this library is basically unmaintained and dead.

Wolf00Bomber commented 6 months ago

Any hope for this library?