Best DevIL version to use? Should ReSIL be used over DevIL?

[ahundt]

I'm trying to figure out which version of DevIL is best to use. ReSIL? DevIL?
In particular I'd like to update homebrew as mentioned in #19

Options include:

• A very sensible set of cmake changes
  • seems like it may be the best option
  • even includes the make install step! this is key
• The sourceforge repo is obviously outdated compared to this github repo
• ResIL, which you recommended on your website in 2013
  • ResIL on sourceforge: http://sourceforge.net/projects/resil/
  • ResIL on github: https://github.com/ScaledLizard/ResIL
• All these interesting fixes, which don't seem like they can merge anymore
  • Include stdlib.h instead of deprecated malloc.h #8

I guess a modicum of minimal help would be appreciated! That would consist of merging the cmake changes release zip produced so I can update the homebrew script.

Perhaps resil has even more high quality changes, but I'd completely understand if you're not available for something larger like that, or even the smaller change mentioned above.

[ahundt]

@bcampbell you may also be interested and/or able to help answer this question if @DentonW isn't available. Thanks!

[bcampbell]

Obviously, I'm biased ;-)
For now I'd love to see some people hammering on the cmake stuff I've been working on.
That probably means using my fork for now, but I'd like to see it merged back into the original @DentonW version if he's still up for that.

The stuff I've been doing is aimed at stabilisation - just tidying up the build system and sorting out issues on various different compilers (mainly to do with inline differences under VisualC vs gcc vs clang and C++ vs c89 and c99...).

I found ReSIL a little opaque and windows-centric, but I've not checked out the github-hosted one yet. Same goes for the other recent activity in the various forks - I've not picked my way through the changes there, but that's the next logical step.

I'm going to be away for the next couple of weeks, but happy to coordinate with any sort of consensus that forms.

I'm not too up on homebrew, but my basic CMake setup seems to work OK on my test mac, albeit in a unixy libs&headers sort of way rather than spitting out a nice, Apple-y .framework. But I suspect libs&headers are probably what you need for homebrew anyway...

Good luck - I look forward to catching up with any activity when I get back!

[bcampbell]

I'm aiming to start collecting patches in my fork (https://github.com/bcampbell/DevIL) for now. There's useful-looking stuff in the various forks on github, and from downstream sources (eg, Debian and some of the BSDs have their own fixes and patches which we should really pull in).

So please feel free to send pull requests my way!

My goal is to get it all stabilised, solid and reliably cross platform. Something people can take away and package (hi, @ahundt!)

[bcampbell]

With that in mind, I'm thinking about ditching support for autotools, and just supporting CMake.

The main rationale is that CMake seems to be a better option for use on windows, and possibly better (or at least no worse) for other platforms.
Supporting both build systems in parallel seems unnecessarily complicated. I think the source would be a lot more approachable with only one of them.

Does anyone have any strong opinions on this?

[ahundt]

@bcampbell since cmake provides generators for many other build tools this seems like a wise choice

[DentonW]

I would definitely like to use CMake exclusively in the future, especially due to its Windows support. I'd like to look at bcampbell's fork soon.

[bcampbell]

Cool - I'll start preparing a branch with all the non-Cmake stuff stripped out, so we can see how it feels. I think it'll be a lot clearer. At the moment, it can be a bit confusing knowing wihich files are part of which build system.

[bcampbell]

OK, so I've made a new branch:
https://github.com/bcampbell/DevIL/tree/cmake_cleanup

In it, I have:

• zapped most of the autotools stuff
• removed the various project files, which should now instead be generated by CMake
• updated some READMEs and deleted ones which are no longer relevant or would now be confusing

I haven't done anything in examples, tests or docs yet.

So, by following the steps in README.cmake it all works pretty smoothly for me under linux (ubuntu), but it'd be nice to get some feedback from people trying it on windows and mac.

[DentonW]

For some reason, the DevIL project under Windows fails at the linking stage with "LINK : fatal error LNK1104: cannot open file 'DevIL.lib'". I haven't yet been able to figure out why it's trying to link against the library that it's supposed to be creating.

[bcampbell]

Found the culprit:
il.h has a #pragma comment(lib, "DevIL.lib") near the top.
il_manip.c is including il.h, and thus trying to link with DevIL.lib.

I think the right solution is that il.h should never be directly included by IL code itself, right?

Anyway, with all, I got it compiling under "Visual Studio 14 2015" with very little hassle, although I've not yet tried to get any of the external libs included - zlib, libpng etc.

By far the most annoying step was waiting while visual studio installed (but only 30mins now, so a big improvement - I remember spending a whole day on it around 2004, feeding in CD after CD and rebooting repeatedly!)

For reference (I'm aiming to turn this into a proper README for visual studio):

• I installed CMake from their standard .msi installer on cmake.org

• I installed Visual Studio

• I opened up cmd.exe and did:

  set PATH=%PATH%;"c:\Program Files\CMake\bin"
  cd DevIL\DevIL
  mkdir build
  cd build
  cmake ..

It automagically picked up the latest Visual Studio version, told me that I was missing zlib etc...
Then I just started VS and opened up the project files it generated in the build dir.

(Oh, I had to remove a list of now-deleted text files from the CMakeLists.txt, but nothing serious - I'll tidy that up)

[bcampbell]

By the way, how useful is it for library headers to have the:

#pragma comment(lib, "DevIL.lib")

line these days?
It's been a while, but I always remember those pragmas being something of a mixed blessing. I'm sort of inclined to think that that stuff should be left up to the users project configuration, not library header files... Does it save a notable amount of effort for users on windows?

[ahundt]

@bcampbell I concur, users of libraries sometimes change library names and extensions or write their own build so it is likely best to avoid that particular type of dep info in headers themselves.

[qrilka]

Are there any chance for a new DevIL release? BTW github doesn't contain any release tags - previous source code version info was lost?
Also Changelog seems to contain only some entries for the 1st half of the year 2009 which looks a bit odd when the repository contains commit from July of this year.

[LiSongMWO]

@bcampbell

The following pragma is specific to MSVC IIRC and will generate warnings to prevent a clean build on other compilers. I would suggest that you replace any occurrence of #pragma comment with linker flags.

#pragma comment(lib, xxx)

[bcampbell]

@EmilyBjoerk: cool I've just disabled the pragma linking in my cmake_cleanup branch (commit 77bc86f).

[bcampbell]

@qrilka: I think it's all still a little chaotic at the moment. The new cmake I've been working on is shaping up nicely for IL now, but I've not yet looked at ILU or ILUT (they should be a lot simpler).
Off the top of my head, the stuff I'd like to see sorted out for a proper release:

• cmake building for ILU and ILUT
• updated documentation
• changelog (have to pick through the logs and figure out what's worthwhile to mention)
• version numbering (need to include it in the build)
• testing! It needs a lot more people to try it out, on all platforms.
• OSX: option to build frameworks

Maybe it'd be a good time to start releasing some developer builds to try and get more people pounding on it? Or even just making it clearer how people can build it themselves - it really is pretty easy now. cmake can be very slick... (windows is the sticking point here - it's a pain setting up all the dependent libraries, even if DevIL is easy to buld with cmake)

[ahundt]

@bcampbell seeing as DeVIL has been dormant for so long I think perfect may be the enemy of good. On many platforms the existing release is already broken, so the sooner the release the better, even with a couple of undetected bugs. They can be stamped out in point releases.

To test on other platforms I suggest creating a travis ci build and/or Appveyor build. Those can automate building and testing on key platforms including linux windows and OS X.

Homebrew will not accept a formulae pull request until there is a release, and that is likely the easiest way to make it possible for users to test it in their libraries on that platform. Particularly considering the current version doesn't even compile at all on OS X if I recall correctly.

Also, might I suggest the inclusion of PackageConfig.cmake generators? Sorry if you have this, I didn't check your code if you've already done it. :-)

• https://github.com/forexample/package-example
• https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-relocatable-packages

[bcampbell]

@ahundt I see your point, and agree. So really, we need a new version number, a changelog, and (ideally) to see my latest cmake_cleanup changes merged into master.
I'll start working toward it.

Agree on the CI stuff.

The PackageConfig.cmake looks good, but I doubt I'll get around to it any time soon - my cmake-foo is already stretched to the limit right now ;- )
I did add some basic pkg-config support, if that's any consolation.

[abma]

DevIL 1.8 was released so i guess this issue is solved! thanks a lot Denton!

[ahundt]

looks like a few CMake pull requests were merged #21 #20 cool!

Anyone test it to confirm it works?

[ahundt]

It's already in homebrew too working via cmake build! https://github.com/Homebrew/homebrew-core/blob/master/Formula/devil.rb

I'd say this is done, closing! Thanks everyone!