sgrogan wrote: ↑
Wed Mar 07, 2018 11:12 pm
kkremitzki wrote: ↑
Wed Mar 07, 2018 9:12 pm
As far as I know that would be
I am willing to be a mentor , but don't know the process to be qualified/accepted, and I don't know if this needs to be done prior to a project proposal being accepted. We would need an additional mentor, I believe we need 2 per project now.
FreeCAD Dependency Graph
kkremitzki wrote: ↑
Wed Mar 07, 2018 4:44 am
There's lots of other things that could fall under this project, though. Thoughts?
I think the first thing is to create a maintainable dependency graph for FreeCAD on Linux/windows (maybe OSX) platforms. And an easy way to update this. Maybe Graphviz? If we can easily pull information from this to keep the Wiki up to date would be hugely beneficial in and of itself.
Sure, Graphviz is nice, or perhaps something with NetworkX which I've used before on a graph theory project.
We need an easier way to maintain packages on the PPA. Building the packages on Launchpad, using gitbuilder has helped, but we need an easier way to generate the Debian folder. Maybe this is just a documented procedure how to do this in a FreeCAD specific context. Your packaging work with upstream Debian is very valuable here. IMHO mirroring the dependent source repo on Launchpad and building there would ease maintenance. After all there will older LTS's that don't have the latest and greatest, and even the newest will become stale from a FreeCAD point of view before they reach EOL.
Right now because I'm still stuck putting extra polish on OCCT 7.2 for Debian, I haven't moved towards making that package available on the PPA because it's undergoing changes. Opencascade-draw is quite a bit of a challenge to get into an acceptable state, but it'll help make it easier to get bugs upstream. P.S. I'm trying to get a change OK'd to rename libopencascade-* -> libocct-*. I am already tired of typing such a long name.
But once that's stabilized it should mostly be a matter of changing the distribution in the changelog to make builds on other platforms, and maybe some bit of patching as well.
It would be nice to have an "Universal" Debian folder (i.e. one that works on Debian) in the FreeCAD source. We could simply use the one from the PPA, but it is Ubuntu specific. The existing one in FreeCAD source is not complete/up-to-date for any modern release.
I can't remember where I read it, but with Debian packaging now they don't recommend keeping the debian/ folder inside the upstream repo. Now that they are running a Gitlab instance, it would be appropriate for this to live inside the Debian "downstream" repository at https://salsa.debian.org/science-team/freecad
Conda is it. @looo has spent hundreds(thousands?) of hours getting us here. I'm able to reliably build release versions of FreeCAD using Conda as a package manager. For now I have to "install" FreeCAD into the conda environment to make it run. First step would be to strip out the runtime stuff from the conda environment to make the build portable without the conda overhead. This is not strictly required, but I think it is presenting a barrier that make some reluctant to adopt.
Yep, I think Conda is the way forward for distribution on Windows as well. Gotta work to make sure it's good on the development side of things as well. I wasn't very satisfied trying to set up a Windows dev VM and trying to Google the download links of some of the dev stuff required in the wiki... only to find it wasn't on Microsoft's website anymore. It'd be nice to have a standard Qt Creator + some non-MS compiler setup.
I am 100% convinced that all needed run and build time dependencies can be stripped out of conda to build a traditional Libpack. I'm 99% that it can be done with CMake as a conda package.
This is always the hardest. I'm the most guilty, but great work get's done/discovered, and I spend many Duck Duck-Go cycles trying to remember what ended up working.
I think at the very least the dependency graph + as much of those dependencies' HTML docs as we can find, searchable, on our website, would be useful to have.