media-gfx/freecad-9999: on startup it cannot find Mod files: No modules found in /usr/Mod

[fordfrog]

i haven't run freecad for quite some time so i'm not sure how long the issue exists, but freecad starts "empty" (no modules etc), that is it cannot find any of its files and if ran from console, it says No modules found in /usr/Mod.

the files are installed correctly in paths like /usr/lib64/freecad/Ext and /usr/lib64/freecad/Mod but freecad still looks at the original path.

the problem might be here: https://github.com/FreeCAD/FreeCAD/blob/master/src/App/FreeCADInit.py#L88-L102

here is what i did to avoid the issue:

diff --git a/src/App/FreeCADInit.py b/src/App/FreeCADInit.py
index e6949134af..f2b0c3f7c3 100644
--- a/src/App/FreeCADInit.py
+++ b/src/App/FreeCADInit.py
@@ -85,18 +85,18 @@ FreeCAD._importFromFreeCAD = removeFromPath

 def InitApplications():
        # Checking on FreeCAD module path ++++++++++++++++++++++++++++++++++++++++++
-       ModDir = FreeCAD.getHomePath()+'Mod'
+       ModDir = FreeCAD.getHomePath()+'lib64/freecad/Mod'
        ModDir = os.path.realpath(ModDir)
-       ExtDir = FreeCAD.getHomePath()+'Ext'
+       ExtDir = FreeCAD.getHomePath()+'lib64/freecad/Ext'
        ExtDir = os.path.realpath(ExtDir)
        BinDir = FreeCAD.getHomePath()+'bin'
        BinDir = os.path.realpath(BinDir)
        libpaths = []
-       LibDir = FreeCAD.getHomePath()+'lib'
+       LibDir = FreeCAD.getHomePath()+'lib/freecad'
        LibDir = os.path.realpath(LibDir)
        if os.path.exists(LibDir):
                libpaths.append(LibDir)
-       Lib64Dir = FreeCAD.getHomePath()+'lib64'
+       Lib64Dir = FreeCAD.getHomePath()+'lib64/freecad'
        Lib64Dir = os.path.realpath(Lib64Dir)
        if os.path.exists(Lib64Dir):
                libpaths.append(Lib64Dir)

atm it does not need any robust solution as freecad is only amd64 but if the Mod and Ext files would be installed to a different location on a different arch, this code should be adjusted.

[waebbl]

I suppose, you're using the live ebuild from my overlay. In a recent commit, I updated the CMAKE_INSTALL_PREFIX passed to /usr. Possibly the issue is related to this update. I check on your patch and update the ebuild.

[fordfrog]

yes, i switched to your overlay as the live ebuild from the main tree did not configure for me for quite some time.

[waebbl]

uh... they're almost identical. What issue do you get from ::gentoo that's not present in the live ebuild from my overlay?

[fordfrog]

atm even the patching does not work

patching file src/Tools/_TEMPLATE_/CMakeLists.txt                                                                                                                                                                                                                                                                    [ !! ]
 * ERROR: media-gfx/freecad-9999::gentoo failed (prepare phase):
 *   patch -p1  failed with /var/tmp/portage/media-gfx/freecad-9999/work/freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch
 * 
 * Call stack:
 *               ebuild.sh, line  127:  Called src_prepare
 *             environment, line 3976:  Called eapply '/var/tmp/portage/media-gfx/freecad-9999/work/freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch'
 *             environment, line 2094:  Called _eapply_patch '/var/tmp/portage/media-gfx/freecad-9999/work/freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch'
 *             environment, line 2032:  Called __helpers_die 'patch -p1  failed with /var/tmp/portage/media-gfx/freecad-9999/work/freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *          die "$@"

some time ago the configuration phase failed but can't get that far atm.

[waebbl]

I had issue with that patch set too, which is why I updated and bumped it lately. Sad to hear, it still has issues (mine were with the Mesh patch). Not sure, whether I should keep this change to using /usr as CMAKE_INSTALL_PREFIX. The versioned ebuild still has /usr/lib64/freecad, which works well and with this issue, I'd like to keep it like this for the 0.19.3 bump.

[fordfrog]

well, imo with this change it seems to work fine except we also need to update some paths because we use different ones from the upstream. but that makes sense to me.

[CaptainBloodz]

Had to patch as follow to build freecad-9999:

--- freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch.old 2022-01-02 12:24:58.105264946 +0300 +++ freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch 2022-01-02 12:51:33.098617103 +0300 @@ -363,8 +363,8 @@ )

--INSTALL(FILES ${MeshTestDataFiles} DESTINATION Mod/Mesh/Data) -+INSTALL(FILES ${MeshTestDataFiles} DESTINATION ${CMAKE_INSTALL_LIBDIR}/Mod/Mesh/Data) +-INSTALL(FILES ${MeshTestDataFiles} DESTINATION Mod/Mesh/App/TestData) ++INSTALL(FILES ${MeshTestDataFiles} DESTINATION ${CMAKE_INSTALL_LIBDIR}/Mod/Mesh/App/TestData)

--- a/src/Mod/MeshPart/CMakeLists.txt +++ b/src/Mod/MeshPart/CMakeLists.txt

[efferre79]

today the freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch is not working anymore

 * Applying freecad-9999-Gentoo-specific-fix-install-locations-of-Ext-and-Mod.patch ...
patching file cMake/FreeCAD_Helpers/SetupShibokenAndPyside.cmake
patching file src/3rdParty/lazy_loader/CMakeLists.txt
patching file src/Gui/CMakeLists.txt
Hunk #1 succeeded at 1343 (offset 1 line).
patching file src/Mod/AddonManager/CMakeLists.txt
Hunk #1 succeeded at 41 (offset 2 lines).
patching file src/Mod/Arch/CMakeLists.txt
patching file src/Mod/Assembly/CMakeLists.txt
patching file src/Mod/Cam/CMakeLists.txt
patching file src/Mod/Cloud/CMakeLists.txt
patching file src/Mod/Complete/CMakeLists.txt
patching file src/Mod/Draft/CMakeLists.txt
patching file src/Mod/Drawing/CMakeLists.txt
patching file src/Mod/Fem/CMakeLists.txt
patching file src/Mod/Fem/Gui/CMakeLists.txt
Hunk #1 succeeded at 405 (offset 2 lines).
patching file src/Mod/Idf/CMakeLists.txt
patching file src/Mod/Image/CMakeLists.txt
patching file src/Mod/Import/CMakeLists.txt
patching file src/Mod/Inspection/CMakeLists.txt
patching file src/Mod/JtReader/CMakeLists.txt
patching file src/Mod/Material/CMakeLists.txt
patching file src/Mod/Measure/CMakeLists.txt
patching file src/Mod/Mesh/CMakeLists.txt
patching file src/Mod/MeshPart/CMakeLists.txt
patching file src/Mod/MeshPart/Gui/CMakeLists.txt
patching file src/Mod/OpenSCAD/CMakeLists.txt
patching file src/Mod/Part/CMakeLists.txt
Hunk #1 succeeded at 90 (offset 1 line).
patching file src/Mod/PartDesign/CMakeLists.txt
patching file src/Mod/Path/CMakeLists.txt
Hunk #2 succeeded at 300 (offset 6 lines).
Hunk #3 FAILED at 323.
1 out of 3 hunks FAILED -- saving rejects to file src/Mod/Path/CMakeLists.txt.rej
patching file src/Mod/Plot/CMakeLists.txt
patching file src/Mod/Points/CMakeLists.txt
patching file src/Mod/Raytracing/CMakeLists.txt
patching file src/Mod/ReverseEngineering/CMakeLists.txt
patching file src/Mod/Robot/CMakeLists.txt
patching file src/Mod/Sandbox/CMakeLists.txt
patching file src/Mod/Show/CMakeLists.txt
patching file src/Mod/Sketcher/CMakeLists.txt
Hunk #1 succeeded at 47 (offset 1 line).
patching file src/Mod/Spreadsheet/CMakeLists.txt
patching file src/Mod/Start/CMakeLists.txt
patching file src/Mod/Start/StartPage/CMakeLists.txt
patching file src/Mod/Surface/CMakeLists.txt
patching file src/Mod/TechDraw/CMakeLists.txt
patching file src/Mod/TemplatePyMod/CMakeLists.txt
patching file src/Mod/Test/CMakeLists.txt
patching file src/Mod/Test/Gui/CMakeLists.txt
patching file src/Mod/Tux/CMakeLists.txt
patching file src/Mod/Web/CMakeLists.txt
patching file src/Tools/_TEMPLATE_/CMakeLists.txt

[oli-nux]

I think the problem is line 323 of the patch. It should look like this. you can find the line easily by searching for " -) ". This combination exists only once in the whole document.

--- a/src/Mod/JtReader/CMakeLists.txt +++ b/src/Mod/JtReader/CMakeLists.txt @@ -8,5 +8,5 @@ INSTALL( FILES Init.py DESTINATION

• Mod/JtReader )
• ${CMAKE_INSTALL_LIBDIR}/Mod/JtReader +)

[efferre79]

No, @waebbl this is the needed patch for patching your patch and solve my problem (I am using gentoo official repo, there is already a bug report https://bugs.gentoo.org/attachment.cgi?bugid=831086):

@@ -560,7 +560,7 @@
  )

-@@ -323,55 +323,55 @@ INSTALL(
+@@ -323,62 +323,62 @@ INSTALL(
      FILES
          ${PathScripts_post_SRCS}
      DESTINATION
@@ -569,6 +569,14 @@
  )

  INSTALL(
+     FILES
+         ${PathPythonGui_SRCS}
+     DESTINATION
+-        Mod/Path/PathPythonGui
++        ${CMAKE_INSTALL_LIBDIR}/Mod/Path/PathPythonGui
+ )
+ 
+ INSTALL(
      FILES
          ${Tools_SRCS}
      DESTINATION
            

[waebbl]

the problem might be here: https://github.com/FreeCAD/FreeCAD/blob/master/src/App/FreeCADInit.py#L88-L102

here is what i did to avoid the issue:

+       ModDir = FreeCAD.getHomePath()+'lib64/freecad/Mod'

@fordfrog This seems not the only occurences of this. Grepping for getHomePath I found, that a lot of Mods use the function to get the base path of their respective Mod. I'm going to check where else this needs to be changed.

IMO a better approach would be to define an ExtPath and ModPath in their mConfig dictionary and proper getter and eventually setter functions and cmake options to define those at configuration time. Three years ago, I started a discussion on their forum about FHS compliance installation locations[1]. From this, I'm sceptic if such changes would be approved, but I was thinking of discussing my idea again. I don't like the idea of getting back to installing into /usr/$(get_libdir)/${PN} just to get this Ext and Mod handling correct.

[1] https://forum.freecadweb.org/viewtopic.php?f=4&t=30596

[fordfrog]

@waebbl i just went through the referenced topic. there was really no usable conclusion. what you write sounds like a clean way of resolving it, but how long will it take before we have freecad-9999 compilable again? currently it fails while patching as mantioned above.

[waebbl]

There will be a PR in ::gentoo today which fixes the patch issues. Fixing the loading of modules could take another one or two days though.