CMake build

[ilelann]

Hello.

To build and run tests with clang/gcc release/debug :
git clone ... && cd adobe_source_libraries && sh cmake_build_all.sh asl_build

It runs all ASL tests OK on my Fedora 22 setup. (GCC 5.1.1, Clang 3.5.0)
Only UT not ported is the "compile-fail" of enum_ops because I don't kwow how to port that to CMake.

Somewhat hidden changes inside the commit :

• removal of boost::next for std::next => fix compile issue with Boost 1.57 on std::reverse_iterator : https://svn.boost.org/trac/boost/ticket/10847
• removal of std::auto_ptr from adobe/memory.hpp => lots of "deprecated" warning removed
• migration to BOOST_AUTO_TEST_CASE for some unit tests => easier cmake setup

I tested that bjam clang build still works.

Waiting for comments,
Ivan

[ilelann]

Regardless of eventual issues in current state, I'd be happy to get feedback on interest for a CMake build.
Before starting to work on an equivalent commit for APL, for instance.

My personal interest for this is that it's lot easier to get into ASL/APL with a real IDE.
One where you can click on a symbol to fetch its definition ... :)
ASL/APL is not a huge code base but still has a non trivial entry cost.
Qt Creator on Linux works well with this commit.

I don't have XCode access. I'd be happy to see someone testing CMake XCode generator and compare against manually crafted ones present in repository.

FYI, I'm also trying this on Windows (MinGW + Qt Creator) and have few code issues, but could build and run adam_smoke test. I might push MinGW specific fixes later.

Regards,
Ivan

[sean-parent]

Thanks much for the changes! Sorry for the delay in responding. Will try and test out the Xcode build soon.

[fosterbrereton]

@ilelann I would be interested to help take up the banner on this. I do have access to Xcode and want to leverage what you have already started. One big question I have: How do you specify paths into Boost? I haven't been able to figure it out in an isolated setup, let alone folding the solution into the CMakeLists.txt work you've already done.

(For ASL, we generally like to build the necessary Boost sources directly, instead of relaying on installed binaries/headers. For our purposes, then, we put Boost into boost_libraries as a sibling to adobe_source_libraries...)

[ilelann]

In main CMakeLists I wrote the classical find_package call.
According to https://cmake.org/cmake/help/v3.0/module/FindBoost.html it handles BOOST_ROOT env var.
I never tested though: I use packaged Boost from Fedora. Will give it a try.

[fosterbrereton]

Let me know how it goes. I might be missing something, but the impression I got was that command was looking for headers and [static|dynamic] libraries, instead of sources. @sean-parent should chime in on this as well, but I would be in favor of a development method that builds the Boost sources as part of the project (or as a subproject dependency) instead of headers and libs.

[ilelann]

You are right, I missed that point. To implement existing sh/bjam workflow (eg. the Boost patch) with CMake I guess one would have to play with ExternalProject.
Can we indeed confirm that it is needed ? Because ExternalProject is not really fun to play with. :-)
BJam handling of external projects is seamless. CMake's is not...

[fosterbrereton]

I am not so interested in the patching as part of the CMake process for day-to-day work. We can always use the bjam path to confirm the patch does what it's supposed to do. It's the ability to manipulate Boost - to create the patch - that I want to make sure is streamlined.

[sean-parent]

I also find it useful for debugging to have the boost IDE projects and I want to make sure we are building boost as static libs (especially true on Mac and Windows where I don't want to add DLL dependencies - less of an issue on Linux). On Mac right now with the CMAKE I'm erroring out on the Boost dependencies and on an OpenSSL dependency (coming in through the sha test code?).

I don't have much experience with CMake so I can't really make a recommendation here on how to proceed.

I'd also like to reduce our boost dependencies where possible - for example with C++11 we can get rid of the boost_threads dependency. I don't think we can easily get rid of all the boost library dependencies though (and in principal I don't object to depending on Boost - just don't want to do so where there is a standard alternative).

[fosterbrereton]

@sean-parent The SHA test code is pulling in OpenSSL for benchmarking. It should be an optional dependency, but regardless shouldn't be a problem on OS X... not sure what's up with that.

Yes, I'm erring out on the Boost stuff, too. It would seem we should make our own Boost sub-projects within the main ASL CMakeLists file, and reference them as dependencies. Looks like I have some learnin' to do.

[kalaxy]

Apple has pulled the OpenSSL headers in their latest OS X SDK. So if you are building with El Capitan then that is probably your problem.