[ci skip] Adding note about libsdl-dev to unix/README.md.

[wfpokorny]

No description provided.

[c-lipka]

This sentence seems pretty convoluted to me.

[wfpokorny]

OK. How about:

"To enable the Simple DirectMedia Layer display also pre-install:"

?

[c-lipka]

Hm... If I already happen to know that I want Simple DirectMedia Layer, I may also already happen to know that I want libsdl-dev.

Maybe be a bit more clear about the fact that it is for the render preview. Also, do we still support X-Window as an alternative? If so, we might want to mention that, too. (Or do we need both for the render preview to work?)

[wfpokorny]

Good point. So maybe something like:

"To enable the render preview display also pre-install:"

No, we don't support an X-Windows display. SDL though still uses X11 for a small subset of functionality and so the X11 library is a dependency of SDL (-lX11 -lXext). In the unlikely case X11 isn't already present on some unix system - the installation of the SDL library will cause all the X11 dependencies to be installed. I'll add a note something like "the --with-x configure option is currently meaningless as no X11 display option is presently implemented."

If we want to go further with updates we should probably strike the text:

"NB if you have improvements to the below instructions, please add a comment
to issue #1, or (if you are working in a branch) send us a pull request."

as this looks like some leftover text from years past to me.

I also think we should not be specifying versions for the following development libraries. Today we have:

zlib1g-dev
libpng12-dev
libjpeg8-dev
libtiff5-dev

where I think we should have:

zlib-dev
libpng-dev
libjpeg-dev
libtiff-dev

Let ./configure determine whether the default versions are OK. In other words, by specifying the library version we are encouraging people to install those versions specifically and they both might be old, and they probably won't be picked up where old.

For example, our png m4 macro today looks for a sequence of library versions in the following order: "png14 png png12 png" using our AX_CHECK_LIB macro. First noting that debian based linuxes are currently planning to jump from png12 to png16 post "Ubuntu 16.04" as "the" png library, folks are going to get png16 on those newer Debians no matter installing png12. In standard set ups libpng will be sym linked to libpng16 for the sanity of the overall install. Drifting deeper, this gets to a ./configure issue in our set up that though systems can have multiple versions of libraries installed in the same standard directories, only one of those is the valid system lib default. If we want to enable use of other than default standard libaries longer term, I think what would might be good is to extend or modify our "--with-libpng[=DIR]" support such so it is something more like: "--with-libpng[=DIR | specifc library version]".

I think adding the the following note a good idea too given what you found with OSX and pkg-config:

Lastly, certain OSX environments do not install the program pkg-config
with autoconf. The program is currently necessary when
determining the link library flags for openexr. In these situations
also install:

pkg-config

I've made all the changes discussed above and will commit and push and update to this pull request shortly. We can further refined the changes if need be.

[c-lipka]

I also think we should not be specifying versions for the following development libraries. Today we have:

zlib1g-dev
libpng12-dev
libjpeg8-dev
libtiff5-dev

where I think we should have:

zlib-dev
libpng-dev
libjpeg-dev
libtiff-dev

That's what I'd have originally thought, too; but I seem to remember having had trouble with at least one of those libraries when I did not specify the version number. Can't remember the details though.

[c-lipka]

Having seached a bit on the 'net again, I guess I've rediscovered what the problem was: In Ubuntu, there are no packages named libtiff-dev or zlib-dev.

[c-lipka]

... oh, and there also doesn't seem to be a libsdl-dev.

[wfpokorny]

It will be usually be the case there will not be a package aligning with the generic names. I'm on Ubuntu 16.04 and when I look for packages I see the following specific versions are available doing queries with the generic names:

apt-cache search libpng-dev

returns: 

libpng12-dev - PNG library - development
libpng16-devtools - PNG library - tools (version 1.6)  (seems to be libpng-config broken out of libpng16-dev) and unsure why listed with the generic name...  

apt-cache search libsdl-dev

returns: 

libsdl1.2-dev - Simple DirectMedia Layer development files

apt-cache search libtiff-dev

returns: 

libtiff5-dev - Tag Image File Format library (TIFF), development files

(Yes, I got the libz generic name wrong in shortening zlib1g-dev to zlib-dev in my last commit)

apt-cache search libz-dev 

returns: 

zlib1g-dev - compression library - development

Testing installs using the generic names above (with -s to simulate the install) works OK for me:

sudo apt-get -s install libpng-dev  (Installs libpng12-dev - only) 
sudo apt-get -s install libsdl-dev  (Installs libsdl1.2-dev)
sudo apt-get -s install libtiff-dev (Installs libtiff5-dev) 
sudo apt-get -s install libz-dev (Installs zlib1g-dev) 

zlib1g-dev gets put into /usr/lib/x86_64-linux-gnu/libz.so and libz.a such that the library link command is the usual -lz form.

libjpg-dev is today libjpeg8 but "apt-cache search libjpeg" shows three version are available with one older and one newer.

Aside. I did the following libpng test too given the new png16 version is coming soon:

sudo apt-get -s install libpng16-dev

and the interesting thing is both that it doesn't allow installation alongside libpng12 and that it removes libsdl1.2-dev for some reason I've been unable to determine. There is an updated version of libsdl1.2 for the Ubuntu release after xenial (17.*) but the changes are to me not obviously tangled with libpng. Guess we need to figure out if Ubuntu 17.04 is at png16 (It looks to be), and if so, whether sdl1.2 is there running OK.

Remv libsdl1.2-dev [1.2.15+dfsg1-3]
Remv libcaca-dev [0.99.beta19-2build2~gcc5.2]
Remv libslang2-dev [2.3.0-2ubuntu1]
Remv libpng12-dev [1.2.54-1ubuntu1]
Inst libpng16-16 (1.6.20-2 Ubuntu:16.04/xenial [amd64])
Inst libpng16-devtools (1.6.20-2 Ubuntu:16.04/xenial [amd64]) []
Inst libpng16-dev (1.6.20-2 Ubuntu:16.04/xenial [amd64])
Conf libpng16-16 (1.6.20-2 Ubuntu:16.04/xenial [amd64])
Conf libpng16-devtools (1.6.20-2 Ubuntu:16.04/xenial [amd64])
Conf libpng16-dev (1.6.20-2 Ubuntu:16.04/xenial [amd64])

[c-lipka]

Testing installs using the generic names above (with -s to simulate the install) works OK for me:

Hmm... having retraced my steps, I guess I may have been thrown off the track by the generic name for zlib1g-dev not being zlib-dev but libz-dev. That, and possibly the fact that the Ubuntu Packages Search on the web does not recognize those generic names.