on my way to build an fc-version with netgen support, I run into nealy every pitfall existing - and no matter what I tried, I did not succeed to build a fc with netgen support. Well, the build works, but problems arise at runtime.
(may be I have to dive into FCs netgen part :O )
So I crawled down the hell of netgens cmake definitions. I never used cmake before, so I needed to scratch cmakes manual ...
Puh - after having visited every cmake-file I guess, netgens author is of the kind: make things as complicated as possible
I don't know why, but it looks to me, as if the author don't want to support shared libraries on windows systems. So he changed most libraries to cmakes virtual library type OBJECT.
The virtual library type has the benefit, that it will never be installed, but need a lot of extra coding, lot of if(WIN32) and of cause, that travel involved a lot of inconsitencies.
Don't know, how FC uses netgen on windows? Doesn't FC need shared libs?
From my very little knowledge of cmake I would say, that goal could have been reached easier.
Anyway - its not my job to optimize build system of netgen, so I only tried to fix the inconsistencies.
Here are all cmake-files, no matter whether it got changed or not
@ulrich1a wrote, that netgen-gui does not work on debian. Don't know, whether that statement is limited to 4.9.13 ...
When I build netgen, I can start netgen-gui and load step-files.
I never got a meshing result - I always killed netgen after several hours ...
... so I can't state, that netgen would work.
So I started netgen with valgrind and loaded a step-file.
The valgrind output shows, that netgen is not stable. May be my source-snapshot is ongoing work?
Anyway - would be nice, to hear, how FC uses netgen on windows systems.
May be it makes sense, to integrate changed cmake-definitions for netgen into fc?