CGAL is pretty cool.

It was tricky to get set up. I was trying to use it as part of a mostly Python utility, and there are SWIG bindings for it that should theoretically have worked, but they were a huge pain and half the core functionality wasn't implemented at all even in the basic 2D kernel. After trying in vain to add the functionality I needed to the SWIG bindings, eventually I just wrote the core algorithm entirely in C++ (despite having no real C++ experience) and called into it from Cython. The API uses enough templated code that it would be hard to get going if you don't have a solid background in C++ or a language with an advanced type system (Haskell in my case).

I didn't find it particularly difficult to get working with Homebrew. Given my scant knowledge of C++ build systems, I would have thought it would be a lot harder. If you are actually a C++ programmer I imagine it would be pretty straightforward.

I agree that the licensing limits its uses quite a bit. The truth is that almost anything you build is probably going to use the GPL'd components. The only things that are LGPL are basic math and the geometry kernels.

I faced similar problems with the SWIG bindings ... almost impossible to add any functionality and they lack quite a lot of features. That's why I started a new set of Python bindings, based off the old ones and using pybind11: https://github.com/wolfv/pygal

> 2. Horrible build system, giant dependency (worse than Boost here)... I wish they had gone header only like Eigen or ViennaCL.

I assume that Eigen went header only because that library is mostly template metaprogramming (and a master class at that).

How is dual licence ugly? It's not expensive for commercial use.

It's quite expensive, especially if you only need one feature from one package that depends on multiple other GPL packages (which is most of them). Everything included we got quoted over $25K for a feature which was decidedly non-trivial, but the cost was still well above the "let's license it instead of re-implementing ourselves" threshold.

Considering

http://www.cgal.org/exact.html

I dare to say that 25K is not that much; if you had to do it yourself, it'd be probably very expensive (of course, I don't know how good you are :-) but you see what I mean).

(and yes, I did 2 years of R&D on quad trees with polygon intersections and "exact computation" is super tough to achieve, you need lots of testing)

25k is actually pretty cheap for this sort of numerical work. That's also licensing about a quarter of the entire library, regardless of how much your actually using.

To put that in context, 25k is roughly the fully loaded cost of a developer month, if they can do this sort of work properly.

Plenty of specialized libraries out there will cost you twice (or more) as much to acquire and a % on your shipped product.

Thinking of this as expensive is either naive, or just the wrong tool for the job.

For the application we were considering and the algorithms we liked from CGAL, exact computation wasn't really an issue. I agree 25K is peanuts if the choice is between developing yourself from scratch or licensing something from CGAL. But in our case the choice was between CGAL, using a simpler and possibly less advanced/less accurate solution, or using an alternative LGPL package. Especially considering the many dependencies most CGAL packages have on other packages, the value proposition for just using a small part of the library for a single algorithm quickly becomes a hard sell...

> For the application we were considering and the algorithms we liked from CGAL, exact computation wasn't really an issue.

So it sounds more like you weren't trying to buy the right tool for the job.

And if you're charging for the resulting software then objecting to being charged in return is simply entitlement.