Request: Single header lib about libimageloader HOT 11 CLOSED

Seems reasonable. Plan to do the same thing I did for my unit test framework and just have a make target that combines everything into one header

from libimageloader.

Yeah I just wanna put one header file and bam, have all these formats support. Although the libraries are checked in a script right? So it can''t be a single header.. or can it? im a bit confused

from libimageloader.

I can provide a single header. You'd still have to explicitly define the libraries you want to use. And your program would still have to explicitly link to them. For example you'd still have to declare something like define HAVE_IMLIB2_LOADER before including the header and then explicitly link with Imlib2. Which may be fine if you know exactly what set you want to use.

A better integration may be to copy the configure script too. It just generates a config.mk (I can make the name customizable) with all the libraries that are installed. This way you could just include this giant header and make will pass in the relevant args. I believe 2 files still qualifies as a single header library according by stb standards.

On the other hand make this repo a sub-module could also work it is small and builds quickly. I'm sure you've already thought of this but just listing it for any one else who stumbles across this issue.

So yes one could have a single header, but you'd need to explicitly enable the libraries. For suckless style software where one is expected to configure the build to their needs it may be a reasonable thing to do. You set a 2 flags and bam you have lib X support

from libimageloader.

I think I would default to make imlib2 a requirement dep. Although, if I use stb_image.h, no dependency will be needed?
I would like something like make libs, which just uncomments some flags I guess.

from libimageloader.

But yes having the configure script and the header lib looks promising

from libimageloader.

The appeal of single header libraries is that they have either no dependancy or only depend on libc. Given that libimageloader is a wrapper library around other image libraries, this to me kills the appeal of a single header lib since I will need to fetch and install the actual libraries and then link to them as well.

Maybe bundling the stb_image library into the single header as well would solve this issue. But even then, the README states the purpose of this library is to be flexible and not force dependancy unto users. Not sure if using a single header would be in line with those goals.

from libimageloader.

The appeal of single header libraries is that they have either no dependancy or only depend on libc.

Sound criticism and basically why I didn't bother in the first place. This is meant to be an library rather than baked into a project.

this to me kills the appeal of a single header lib since I will need to fetch and install the actual libraries and then link to them as well.

I think there is still some benefit. I'm imaging the case where one already has the libraries they want to use and just wants to integrate them into the program. Using this lib takes the burden of of the higher level application and makes it pretty easy for the user. Whether this lib is treated like an 3rd party depend, submodule or a single header is just a small detail. It shouldn't take much to just combine all the files into one to give more options. And the configure script should inject all the flags needed to use and link the libs so that shouldn't be a headache.

Yeah it isn't as convenient as normal single header libs, but there are also a few stb libs that rely completely on external libraries so it isn't unprecedented.

from libimageloader.

That's fair, just using the lib as a higher level abstraction without caring about dep will maybe benefit from having a single header.

Also on the topic of deps, it looks like to me that all the loaders are hardcoded into an array. I suppose it's not possible to add or subtract a loader without recompiling the library then?

I think a better approach might be doing things in a more modular way similar to what Imlib2 is doing; all the loaders are shared lib and they get loaded at runtime from (i believe) $CWD/loaders/*.so.

This means removing a loader is as simple as taking it out of the folder and adding a (potentially 3rd party) loader is simply putting the shared lib into that folder. No need to recompile the library itself. Which I think is a more suitable architecture for a library that's trying to be user choice friendly.

from libimageloader.

@explosion-mental Have a sample at https://github.com/TAAPArthur/libimageloader/tree/single_header

Haven't fully tested, but that's should be a good enough proof-of-concept.

I suppose it's not possible to add or subtract a loader without recompiling the library then?

Correct. Well kinda. I was debating about having an option to disable an arbitrary subset of loaders. Of course the application itself shouldn't do it, but it could expose the option to the end user. I was imaging something like an enable/disable interface where one passed in a enum representing the loader to enable/disable. Or maybe a bitmask.

adding a (potentially 3rd party) loader is simply putting the shared lib into that folder

I don't see the usecase of adding. For one a loader requires private functions and it seems easier to just patch the library. Also there's some risk as some applications (like Img2lib) leak memory as reported by valgrind just by being loaded. As for general 3rd party loaders... the only reason I would imagine I wouldn't expect a PR to just include them officially was because the api was convoluted and if someone was that determined patching should be pretty straight forword

No need to recompile the library itself. Which I think is a more suitable architecture for a library that's trying to be user choice friendly.

I'm generally assuming that the end user has some preferred img loader lib(s) that fit there needs. And given it does they don't want to install another lib. Like if one was using stb_img, there's may not be a need to have to drag in img2 just to use an image viewer. I guess you may have both and want finer control of which is tried first to load an image. Unclear on what a good interface for sorting would be. Probably wait for an issue to be opened to see if the current control isn't sufficient.

For recompiling, I'm imaging the people who would care about this are used to suckless-style software where you just recompile for every little change. I also prefer non-dynamic library loading as you can tell what a program will do just by looking at it.

from libimageloader.

I think I understand a bit better. You are suppose to go here and make install this library.
Then, a program that requires this simply 'links' (¿) to this library by a flag in the compiler.

from libimageloader.

I think I understand a bit better. You are suppose to go here and make install this library.
Then, a program that requires this simply 'links' (¿) to this library by a flag in the compiler.

dummy

from libimageloader.