libarea dependency

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
looo
Posts: 3175
Joined: Mon Nov 11, 2013 5:29 pm

libarea dependency

Postby 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...
please help with my conda-packaging efforts: https://liberapay.com/looooo/
minimalistic blog: https://looooo.github.io/mini-blog/
mlampert
Posts: 1460
Joined: Fri Sep 16, 2016 9:28 pm

Re: libarea dependency

Postby 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.
wmayer
Site Admin
Posts: 15471
Joined: Thu Feb 19, 2009 10:32 am

Re: libarea dependency

Postby 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
Posts: 395
Joined: Fri Oct 07, 2011 8:58 pm
Location: Beaverton,Oregon, USA
Contact:

Re: libarea dependency

Postby 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.
User avatar
looo
Posts: 3175
Joined: Mon Nov 11, 2013 5:29 pm

Re: libarea dependency

Postby 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?
please help with my conda-packaging efforts: https://liberapay.com/looooo/
minimalistic blog: https://looooo.github.io/mini-blog/
User avatar
yorik
Site Admin
Posts: 11686
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: libarea dependency

Postby 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
User avatar
saso
Posts: 1413
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: libarea dependency

Postby 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
User avatar
looo
Posts: 3175
Joined: Mon Nov 11, 2013 5:29 pm

Re: libarea dependency

Postby 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.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
minimalistic blog: https://looooo.github.io/mini-blog/
wmayer
Site Admin
Posts: 15471
Joined: Thu Feb 19, 2009 10:32 am

Re: libarea dependency

Postby wmayer » Tue Mar 28, 2017 7:01 pm

But then we should also include pivy?
-1 Please not again.
User avatar
yorik
Site Admin
Posts: 11686
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: libarea dependency

Postby yorik » Wed Mar 29, 2017 1:13 pm

wmayer wrote:-1 Please not again.
:D

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 :)