libarea dependency
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
libarea dependency
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...
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...
Re: libarea dependency
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.
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.
Re: libarea dependency
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.
-
- Posts: 395
- Joined: Fri Oct 07, 2011 8:58 pm
- Location: Beaverton,Oregon, USA
- Contact:
Re: libarea dependency
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.
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.
Re: libarea dependency
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?
Why not having an official libarea fork and maintain via a separated package?
Re: libarea dependency
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
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
Re: libarea dependency
+1yorik 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
Re: libarea dependency
Thanks for clarification. If that is the case, I have no problem with this. But then we should also include pivy?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
At some point we may have to think about better modularization... But we had this discussion already.
Re: libarea dependency
-1 Please not again.But then we should also include pivy?
Re: libarea dependency
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