CMake support for OS X and Linux
SIMD-accelerated libjpeg-compatible JPEG codec library
Brought to you by:
dcommander
Menu
▾
▴
I don't like explicitly setting NASM to the MacPorts version. This is really something that should be specified on the CMake command line. I will look at the rest for possible inclusion. What project are you using this for?
The explicit set makes imo sense since the default nasm in /usr/bin does not work, but will always be found be CMake first. One can still override /opt/local by setting NASM on the CMake command line. Most people will simply end up using the MacPorts install, I suspect.
I'm using it as an image compression plugin for the Equalizer parallel rendering framework (http://www.equalizergraphics.com). Feel free to email for more information.
Regarding NASM, the version in /usr/bin will work for building 32-bit code. It just doesn't work for 64-bit. Our convention is to not set a tool variable such as NASM to a platform-specific value but rather to document "build recipes" for 64-bit and other cases which require overriding these variables.
Also, a couple of things make me nervous about other projects sourcing our SVN tree. This means that when we check something in, we potentially break your build and not just ours. It also means that we're put in the position of supporting additional types of builds (such as CMake on OS X) that we don't otherwise support. We have decided to standardize around autotools for Unix-like platforms and CMake for Windows in libjpeg-turbo 1.1, and I don't like the idea of adding additional platforms to the CMake system until/unless we decide to eliminate autotools (that will likely happen down the road, but right now we're trying to stabilize for 1.1.)
I am not completely closed to this idea, but I need more convincing as to why sourcing our SVN is a better solution for you than just using one of the pre-built SDKs or simply checking in the source for a specific stable release into your repository (the latter is what we do with TigerVNC, which was the project that launched libjpeg-turbo.) As a project maintainer, I would personally be nervous about sourcing someone else's trunk unless I had a working relationship with the sub-project and could ensure that it never broke my project.
If this solves a problem that can't be solved otherwise, then I am open to it, but I would really rather not do it unless absolutely necessary.
Re NASM: Your call, I was just voicing my 2c. I can set it externally.
Re SVN: We would source your svn tree at a given revision (see svn:externals), and update the revision typically to a release tag. I would definitely not reference HEAD.
Re CMake: We would like to build libjpeg-turbo with the rest of our build to not have to check in n binary versions of your builds (Window, Linux, Mac X 64/32 bit x debug/release). We could also just check in the source at a given rev, but to me this is the same as svn:externals with a fixed revision.
Using CMake on all platforms makes the integration in our (any) build system much easier then having a if( windows ) Cmake_recipe(); else autotools_recipe();. I also do not see the benefit of autotools over CMake (esp. since you use it on Windows), but that's your call again.
To summarize: I would like to use CMake on all platforms, but can work around it. We would also test/fix it on Linux soon.
Cheers,
Stefan.
Fair enough. I'm going to need to defer this until after 1.1, however. It actually ties in quite well with our long-term goal of eliminating autotools from the libjpeg-turbo build (which is a dependent of the long-term goal to do the same for the TigerVNC Project.) If we do this as part of the same build system overhaul in TigerVNC, I can probably secure funding for it, whereas I'd have to do it for free if I did it now. There's a lot of hidden labor involved in testing the build on the various Unix platforms, and it's easier to do that all at once for a handful of supported platforms rather than one platform at a time.
Please post the Linux patch once you have it.
I've updated the patch to work for 64 bit Linux as well. 32 bit Linux should be trivial to add, but I don't have a system at hand.
Marking as "Postponed". I need to finish adding CMake support to VirtualGL so I can get a feel for the general issues associated with using CMake as a build platform on Unix systems. My initial impression of it is that there are some sticking points, such as the fact that it doesn't handle cross-compilation as well as autotools does.
There is currently too much traction with the autotools system among libjpeg-turbo developers, particularly with the addition of Java support and ARM support in trunk, to consider switching build systems anytime soon. There is also a desire to maintain the same build system as the upstream project so as to more easily adopt build changes that they may make in future releases.
TigerVNC is no longer including libjpeg-turbo in its tree. We are building against the libjpeg-turbo SDK instead, so there is no longer a desire (nor funding) from within that project to move libjpeg-turbo to CMake.