Find Netgen/nglib on MacOS with MacPorts

[ianrrees]

This should allow for building in netgen support on Macs using MacPorts, assuming the ticket at https://trac.macports.org/ticket/50687 is accepted. It's not intended to change any behaviour unless MACPORTS_PREFIX is defined.

@peterl94 - Let me know if you run into problems making up a Homebrew recipe. I ended up making the MacPorts port just copy the entire libsrc directory to the MacPorts equivalent of /share/netgen/libsrc .

[peterlama]

Great! I'm a bit curious why there are multiple libraries? Seems like there was only one shared library last time I built it on a mac, maybe I'm confusing that with windows. Also, /share/netgen/libsrc is a debian thing. I guess maybe it is because the libsrc headers weren't meant to be public headers, but putting them in /share seems wrong to me. It looks like the fedora package puts them /usr/include/netgen-mesher/private, same level as nglib.h. Anyway, not saying it is worth changing, just I personally find the debian choice strange.

[ianrrees]

The extra libraries are there because I ran into missing symbols when linking FreeCAD against just the one library. I started modifying the Netgen source to fix the exports, but then realised that it was just putting the 'missing' objects in those additional libraries. I didn't want to change the Netgen source too much since there was already a Netgen Portfile in MacPorts (for the application but not nglib), and it was starting to seem like more work, but either way is probably possible.

Agree that /share seems a bit weird, but in a way it fits because the Netgen #include scheme is also a bit weird ;). I was just following what the FreeCAD cmake file appeared to have done before, but am not attached to using that directory.

[peterlama]

Ah, makes sense. Now I know the cause of the missing symbols.

One more thing (not related to this patch), are you copying everything in the libsrc folder? I remember only copying *.h and *.hpp for the windows lib pack.

[ianrrees]

Hmm, well let's just say it's not copying anything but headers now :). I'm just doing a quick test and will submit a new patch and also move the headers into include/netgen . Thanks for catching that!

[ianrrees]

@peterl94 Sorry I haven't had any time to work on the Homebrew side of this in a ~week.

If you get some time, mind having a look at this PR in conjunction with https://github.com/ianrrees/homebrew-science/tree/20160320-add-nglib ?

Edit: Updated URL (and fixed a couple things about the formula)

[peterlama]

I won't be able to try it until Sunday. So far it looks fine to me.

[ianrrees]

Sounds good, no rush! I finally got a formula for nglib to work, pass the audits, and pass the Homebrew CI stuff - https://github.com/Homebrew/homebrew-science/pull/3455 . Had a bunch of headaches with line endings in the netgen source code making patches difficult, but think the current version should work OK unless people want to use old opencascade versions for some reason.

[wwmayer]

I have tested it on Ubuntu 12.04, Ubuntu 14.04 and Windows and there it works fine.
However, on OSX when using netgen 4.9.13 it does not work.
The version 4.9.13 only creates a single shared library "libnglib.dylib" so it would suffice to offer only one entry in the CMake settings. However, it also works to set all entries to the same library.

But the real problem then appears when trying to build the netgen plugin of the smesh sources. Here I get a compiler error:
NETGENPlugin_Mesher.cpp:694:28: error: too many arguments to function call, expected 0, have 1
which happens because the preprocessor macro NETGEN_V5 is set.

When using netgen 5.1 instead then everything works fine, too.

IMO, both netgen versions should be supported because on Windows and Ubuntu the default version is also 4.9.13 IIRC. If it's too complicated for cmake to automatically find the used netgen version then I think it is OK to make an option and let the user decide if it's version 4.9.x or 5.x.

[wwmayer]

Two more remarks:
IMO it's plain wrong to add any entries to ADD_DEFINITIONS inside the FindNetgen file. The proper way is to set it to a variable and let the programmer add this variable to ADD_DEFINITIONS where needed.
It can be done like this:
SET(NETGEN_DEFINITIONS "-DNETGEN_V5")
...
ADD_DEFINITIONS(${NETGEN_DEFINITIONS})

Second remark:
This was already wrong in the original file. Preprocessor macros must not be added to the list NETGEN_INCLUDE_DIRS which you then add to include_directories() because this may easily fail with future cmake versions. The correct way is to add them to the variable NETGEN_DEFINITIONS.

[ianrrees]

Thanks for looking at this Werner, I'll make some changes soon.

Where did you find the netgen 4.9.13 library? I'm thinking that you must have gotten it from outside of Homebrew/MacPorts, so the approach I'd be tempted to use for determining whether it's version 5 or not wouldn't work in your case.

Still haven't heard back regarding the Homebrew or MacPorts scripts to install nglib. But, since we can host the Homebrew formula on a separate github (I'm doing that already), we could make use of these changes as soon as they're merged into FreeCAD.

[wwmayer]

Where did you find the netgen 4.9.13 library?

It was definitely outside from MacPorts/HomeBrew. IIRC it was from taken from Sourceforge.
Anyway, if it's too difficult or too much work to support 4.9 then just leave it since I got it already working with 5 (also self-compiled). Since there is now also a MacPorts/HomeBrew recipe I can switch to that.

Nevertheless, it would be cool if you could fix the other two issues.

[ianrrees]

Fixes compile warning.

[ianrrees]

I've made some quick edits to implement those changes - only tested on my MacPorts system so far.

Didn't get a chance to look into detecting the netgen version, but we'll almost certainly need to do some more work in this area whenever we are using nglib >5 so could address it then. FWIW, it looks like that -DNETGEN_V5 is used for the WIN32 target in the salome CMakeLists.txt

[ianrrees]

Sorry, my OCD made me clean up the tabs...

[ianrrees]

@wwmayer - the nglib recipe has been merged in to homebrew-science, so if you and @peterl94 are OK with the changes here, could we pull this in to master before 0.16? -Ian-

[wwmayer]

Works well on Ubuntu and Windows using netgen 4.9.13. Merged now.

[ianrrees]

Thanks Werner!

@bblacey - Next step with this is to add nglib (--with-oce or --with-opencascade depending on which we're using) to the homebrew dependencies, and -DBUILD_FEM_NETGEN=1 to the cmake args.

[bblacey]

Cool! I will take are of enabling this in the build integration today/tonight. I'm sure the OS X community will appreciate your efforts to close another OS X gap.

That said, the logic here seems a bit convoluted given netgen/nglib mesher support across platforms. Currently, it is:

1. Turn on FEM by default (all platforms)
2. Turn on FEM for Windows (why?)
3. If not Windows, turn NETGEN mesher off

Shouldn't this coalesce to:

1. Turn on FEM (for all) by default. (provide override to turn FEM off)
2. If FEM on, enable NETGEN mesher

IMHO, you should be able to build out-of-the-box with default options. While it is manageable on Travis, it is harder for NOOBs who come along and want to bootstrap and environment to contribute (reduce/eliminate the "Sherlock Holming" they would need to do in order to achieve local build parity with downloaded build/PPA)

[sgrogan]

I think.
At the start FEM worked windows only. Then FEM worked on all platforms, but without netgen support.
At present netgen support works out of the box on windows using the FreeCAD provided libpack.
Hopefully ian's work makes netgen support work out of the box on Mac.
On linux netgen support is still sketchy. Works for ubuntu using the netgen headers and oce from the FreeCAD PPA but not for the default nglib and oce from the Ubuntu repos.
This is a tough nut to crack. The nglib library(s) seem to be differently named and installed for different versions and different distros, and nglib depends on the oce version.
TLDR

1. I think this is correct
2. I think this is probably redundant, I'll try to confirm
3. Should be if linux NETGEN off

for coalesce

1. Should be possible now
2. As wmayer has pointed out in the past, we need a smart (call it genius) cmake to work this out for linux especially, but for anyone on windows not using the libpacks or on mac not using ian's work.

[ianrrees]

I like the idea of having the default options produce something like the nightly downloads too, but more importantly align with the compile instructions on the wiki (I'll update the Mac ones to reflect these changes soon).

Would personally prefer to have a few more people confirm the BUILD_FEM_NETGEN works OK on MacOS before enabling it by default, but would be nice to have that default set by 0.16 too...

[bblacey]

Ok, I have integrated the netgen/nglib into the integration branch on my forked repo (also into the FreeCAD/FreeCAD-ports-cache. Barring any unforeseens, Travis should crank out build 6669 under the Releases section of the forked repo - feel free to take it for a spin.