CGAL users discussion list

[Phil Weir <>]

Hi Tony,

Not a member of the project but currently spending today digging
through CGAL stuff, so thought I'd chip in:

On 03/02/2016 02:41 PM, tcscott wrote:
> Hello again
>
> THX. At least this tells me what my problem is but I submit this is 
wholly
> unacceptable for any new
> user with a MAC. It means I cannot work out the demos nor visualize the
> CGAL data structures on a MAC.

As far as your previous emails suggest, the two difficulties you 
experience are:

(a) the unrelated MacPorts package, which someone somewhere has
decided to create, has installation issues (but you are reluctant to
raise them in that project for reasons that remain unclear). An
example of someone doing so is here:
https://trac.macports.org/ticket/48718

Binary packages for Debian, Ubuntu, Fedora, Debian, Windows, RH etc.
will also have their separate downstream bug trackers and package
maintainers, so Mac isn't special here. As there are an unknown number
of possible platforms, all with their own caveats, it is not practical
for upstream developers to take responsibility for managing all of
them in any large project, whether CGAL, Qt, GIMP, Linux, KDE or
otherwise. (If this source / binary separation isn't familiar, then
this is a far more general pattern than CGAL, so there are probably
better forums to get into that discussion if you feel it doesn't suit
your needs.)

On the other hand, I come from a maths, not development background, so
gaining adequate developer skills is possible and allows you to be
independent of these platform-specific binary projects, going straight
to the source. Which brings me to:

(b) as an alternative to binary installation, you have tried source
installation. However, not being familiar with dependency handling or
CMake, it is hard - for example, a person familiar with CMake, but not
CGAL, would have avoided the issues you experienced. Several obstacles
you mentioned as being Mac-specific issues, were not - I'm pretty sure
you would have got the same output from the same input on any
Unix-like platform. As CMake is a very standard cross-platform
development tool, it is not the responsibility of the CGAL developers
to re-document it, so I would suggest starting with a few CMake
projects to get the hang of it. There is nothing in the CGAL
documentation that suggests you can build the source distribution with
no familiarity with standard C++ compilation tools, nor should there
be.

>
> I have to think if I should even bother continuing with CGAL.
>
> So much code.
>
> So much effort.
>
> but clearly the MAC version for this code is something of a bust.

From your other emails, I can't see any indication that there is a
genuine problem with the CGAL code, and other Mac users have confirmed
it is working, but you seem to be expecting binary support from an
upstream library source project. The compilation problems sound more
like a CMake documentation issue, or something that would be helped
with practice - there may well be CGAL bugs in the CMake scripts, but
the most helpful contribution you could make would be to get familiar
with CMake, isolate the problem, and file a bug report. If you don't
want "so much code", then a binary is your only option, which means
filing a bug in the right place, with the binary distribution.

If you genuinely think there is a problem with compiling the code on a
Mac, other than inexperience working with CMake-built code in general,
it would be good to clarify that, but there doesn't seem to be
evidence from what I have seen so far. To encourage you, you seem to
be getting closer, but I, along with many others depending on this
project, very much appreciate the effort the CGAL developers put into
their core jobs, and this thread has begun to drift away from
CGAL-specific problems.

In summary, for anybody else using a Mac who comes along later,
working with this code on Mac is unlikely to be different from other
platforms, never mind a bust, at all.

I hope you are successful in getting CGAL up and running on your
machine - the code development skills in doing so are transferable to
many other projects.

With best wishes,
Phil