Take a look at include/lcdfgif/gif.h and similar functions.

I won't be able to give you instruction or guidance.

the same requirements need a lib .so

@kohler I'm wondering, would you be open to PRs that help make this easier?

Right now the biggest issue I'm experiencing is that everything is all compiled into the binary. So while the gif.h file defines many of the functions needed to use this as a library, it's not that straight forward.

For example, with ImageMagick the binary executables all utilized dynamic/static libraries of code. So while it does have the magick binary, if you delete the .la files from the lib folder then the binary breaks.

I believe that if we tweaked how gifsicle is built, at least on Unix/Linux, then it will facilitate easier methods to use it as a library. I have a local branch where things a configured to build a libgifsicle.la file, this is built to include:

• clp.c
• fmalloc.c
• giffunc.c
• gifread.c
• support.c

Then all the gifsicle related binaries loading this .la file. The .h files are also then installed on the system so that they, along with the .la can be utilized as a system level library. I believe that if gifsicle were configured to compile like this that any other system library or tool to utilize it's function easier.

My specific goal is to eventually build a PHP extension for Gifsicle. However at this time I don't think that's easily possible without directly loading the gifsicle source into my extension and compiling them all together. However, from my experimentation, doing this method of compile does seem to make that easier to manage.

High-level comment is this would be a difficult route to go, and although I'm open to PRs, it's not super likely to achieve success. Large refactors might make it harder for me to maintain. The refactor you describe doesn't achieve very much.

I may have done a poor job explaining things, as your reply doesn't seem on the same page as my suggestion. I will try to clarify and hope it will make more sense than my first post.

I'm not suggesting a refactor in any significant manner - which is to say that I certainly would not consider my suggested changes a refactor. I'm simply suggesting a change in how the make script is setup. I think the branch I was testing this in has only a handful of lines changed in the Automake file and that's it. Everything else is handled by the build process itself.

Further I don't feel like what you said at the end is accurate in any sense at all. Here:

The refactor you describe doesn't achieve very much.

Maybe I'm just misunderstanding you though due to lack of knowledge in how you've suggested people reuse this package as a library. You said to reference the gif.h file, which will work in theory. However, as things are now, gifsicle packages don't ship with their source code, or any published header files. Please let me know if I've misunderstood your suggestion.

If I haven't misunderstood your suggestion, then it stands to reason that this minimal effort change drastically improves the interchangeability of Gifsicle with other Unix programs.

I've created a PR(#139) as it likely will better demonstrate why I believe my suggestions aren't a 'refactor' and are in fact quite minimal.

If you're still not feeling up for this idea then no worries. I'll simply look about building my PHP extension idea with the Gifsicle code all wrapped right into it. Unfortunately this may make my end extension larger and, more importantly, would mean users could now have two different versions of Gifsicle on their system (i.e. one as their CLI/system command and the other built directly into the PHP extension).

However that's not a deal breaker for me I guess - I still think the PHP world could benefit from a Gifsicle extension, so for me it's still worth making even if less than ideal.

In my opinion a library that is only realistically useful for one set of executables “doesn’t achieve very much”. Making a library adds maintenance overhead and generally libraries have expectations of API stability. You may need to explain what you want your PHP extension to do. If you are looking to access Gifsicle's GIF writing and optimization features, the libgifsicle.la idea you propose is not sufficient.

As Imagick is to ImageMagick, my extension would be to Gifsicle.

Imagick for PHP is a pretty simple 'wrapper' for the ImageMagick library (and commands). It's used to do all sorts of things to images within PHP that you would normally need to run via CLI. The benefit to the PHP Imagick extension, over just running the command in PHP via shell_exec, is that it's much safer, more compatible and easier for end users to use.

By using my branch I've been able to successfully create a proof of concept (albeit in rust) that does in fact seem sufficient to utilize Gifsicle methods within another language. Perhaps my proof of concepts doesn't stretch things far enough for me to hit the issues you are expecting.

I think i'll just take your advice and forget about the idea of using Gifsicle as a static or dynamic library. Maybe there are other tools I can use for GIF manipulation within PHP instead of gifsicle, or maybe my best option is just to sync this repo into my extension at compile time and just let the PHP module include this full source.

That sounds like the place to start for sure. I'm much more sympathetic to a PR that makes it possible to include all of Gifsicle, minus the main function, into another program in a useful way. Such a PR might start by moving most of main into another function. Perhaps the next thing to add would be a way to specify GIF inputs and outputs that are memory streams.