DentonW / DevIL

Developer's Image Library (DevIL) is a cross-platform image library utilizing a simple syntax to load, save, convert, manipulate, filter, and display a variety of images with ease. It is highly portable and has been ported to several platforms.
http://openil.sourceforge.net/
GNU Lesser General Public License v2.1
446 stars 138 forks source link

fix visual studio 2012 compilation #43

Closed Agadoul closed 7 years ago

bcampbell commented 7 years ago

Thanks - I've merged it into my fork, which I'm using as sort of a staging zone for getting stuff into the main DentonW repo.

Agadoul commented 7 years ago

No problem.

bcampbell commented 7 years ago

There are already a few files in DevIL which require C++ compilation as they link with C++ libraries. It's a little moot on Visual Studio, as nobody actually uses the C compiler anyway, other than people writing device drivers. I think you have to jump through hoops to even use it.

Here are some notes on this I wrote to myself a few months back:

C vs C++
---------

I've just been trying to compile IL from source (using CMake on Linux), but have run into some issues.

There seems to be a little mixing of C and C++ within src-IL.

The offending formats are:
  * `il_exr.cpp` (in order to use the openEXR libs, which is a C++ interface)
  * `il_squish.cpp` (because libsquish is a C++ interface?)
  * `il_utx.cpp` (no external library used, but a few C++-isms in the source)
  * `il_nvidia.cpp` (the nvidia texture tools lib is a C++ interface)

First off, I'd say that I think it's important that DevIL continues to present a plain C interface to the world - there's a lot of C code out there. and there's nothing in the public API that justifies requiring C++.

That said, it seems insane for DevIL not to use the openEXR, libsquish and nvtt libraries, which means some C++ is needed. The solutions I can see are:
  1. switch to compiling DevIL with C++ (which I guess is what happens already most of the time). I _think_ the resulting library can be used fine from C, as long as all the public interface functions are all declared as `extern "C". ([here's what wikipedia says about it](https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B#Linking_C_and_C.2B.2B_code))
 2. write little shim libraries which hide away all the C++ and present C versions of ilLoadExr() which DevIL can statically link to.
DentonW commented 7 years ago

When DevIL was started 16 years ago, I think the rationale was that there weren't a lot of good freely available C++ compilers out there. Times have obviously changed lots, and it's interesting getting back into this after being mostly away for 7 years.

bcampbell commented 7 years ago

Oh yeah, C++ support was shockingly bad for a decade or two there :- ) But even today there are still a lot of good reasons to keep the library in C ABI compatible (even if it's C++ behind the scenes). There are a lot of people and projects still using C (especially out there in Linux-land), and C is a great lowest-common-denominator for doing bindings for any other language.

DentonW commented 7 years ago

I'll agree with having a C-style interface so that we can use it from other languages easily. I need to figure out what the best path forward to make it thread safe is (the whole binding process for images is pretty antiquated, I feel).