libarea dependency

looo · Post by **looo** » Mon Mar 27, 2017 2:40 pm

After trying to build FreeCAD with Path enabled there was a message about boost-python requirements. After some research I found libarea causing this dependency.
In my mind we should think of an alternative way to handle this dependency. If we keep this copy-pasting of libraries into our source-code we will have issues like we already have with smesh... (upstream updates, we are way behind, porting has to be done ...)
Would it be possible to build libarea as an external project and import it? Is it used only from python or are the the c++ libraries also used? Looking at github, libarea is actually a project on it's own. So including it in our source is really a strange choice.
But maybe I am missing something...

mlampert · Post by **mlampert** » Mon Mar 27, 2017 5:42 pm

I missed the boost-python dependency - I agree with everything you said.

Having said that, sliptonic is currently looking into making libarea a core component of Path, so we probably need to wait for the results of that to figure out what and how to deal with this.

Post by **wmayer** » Mon Mar 27, 2017 6:04 pm

Quite a few changes (mainly realthunder) has been applied to the libarea source code that is in our repository. So it must be checked how to handle these changes.

danielfalck · Post by **danielfalck** » Tue Mar 28, 2017 1:43 am

Any libarea repos found outside the FreeCAD source are going to be incompatible and not maintained at this point. I might be wrong, but think I remember that the boost lib was used for python bindings in libarea, starting way back in the HeeksCAM days. So another approach might be to come up with a different way of dealing with the python interface to it.
I don't think anyone will get much support trying to pull libarea out into a separate repo at this point. It is at the heart of the Path workbench.

looo · Post by **looo** » Tue Mar 28, 2017 5:11 am

I have no problem with boost-python. But copying source code from another repository to FreeCAD isn't a nice way to fork a repo. Looking at the history, mainly build-fixes (which are freecad specific), some additions and some fixes were done. https://github.com/FreeCAD/FreeCAD/comm ... th/libarea On 9 Jun 2016 there was even a pull from the origin repo.

Why not having an official libarea fork and maintain via a separated package?

Post by **yorik** » Tue Mar 28, 2017 1:34 pm

I think what Dan is saying is that libarea has become unmaintained (it was part of HeeksCAD and there is an official statement on the heekscad page saying it is not maintained anymore), so our fork is not a fork anymore, it's now the "official" version. If, by being nested inside freecad, it stays alive and maintained, I think it's fine for everybody, no?

I think the only thing we should take care of, is making sure it doesn't depend on freecad, so it can still be forked from us, and used by other projects

saso · Post by **saso** » Tue Mar 28, 2017 1:43 pm

yorik wrote:I think what Dan is saying is that libarea has become unmaintained (it was part of HeeksCAD and there is an official statement on the heekscad page saying it is not maintained anymore), so our fork is not a fork anymore, it's now the "official" version. If, by being nested inside freecad, it stays alive and maintained, I think it's fine for everybody, no?

I think the only thing we should take care of, is making sure it doesn't depend on freecad, so it can still be forked from us, and used by other projects

+1

looo · Post by **looo** » Tue Mar 28, 2017 2:53 pm

yorik wrote: I think what Dan is saying is that libarea has become unmaintained (it was part of HeeksCAD and there is an official statement on the heekscad page saying it is not maintained anymore), so our fork is not a fork anymore, it's now the "official" version. If, by being nested inside freecad, it stays alive and maintained, I think it's fine for everybody, no?

I think the only thing we should take care of, is making sure it doesn't depend on freecad, so it can still be forked from us, and used by other projects

Thanks for clarification. If that is the case, I have no problem with this. But then we should also include pivy?
At some point we may have to think about better modularization... But we had this discussion already.

Post by **wmayer** » Tue Mar 28, 2017 7:01 pm

But then we should also include pivy?

-1 Please not again.

Post by **yorik** » Wed Mar 29, 2017 1:13 pm

wmayer wrote:-1 Please not again.

We've had HARD times with pivy. And now it's in the hands of package managers of all big distributions, so, no, thank you very much, pivy

libarea dependency

libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency

Re: libarea dependency