Because of overly creative developers, some libraries are called "libfoo.uno.so" instead of "libfoolo.so" -- this causes needless complexity in the build system. Since there is no technical reason to name them differently, this should be fixed. Here is an example commit: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=1cfaf70d401d49ab5a2c353f256203e086a678dc In the end (when UNOLIBS_OOO is gone) this hopefully reduces the complexity of the build system and the barrier to entry for new contributors.
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef08518fcfdab0e5fd5c61aa4fb4f7907fcb8355 fdo#60949: Move some libs to OOOLIBS The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5414a3eecdb09be928313477792acfe1d3534645 fdo#60949: Move more libs to OOOLIBS The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi guys, I saw some cases that we just have SPECIAL_COMPONENT_LIB_FILE(gid_File_Ucpext, ucpext.uno) Do we need to change this to SPECIAL_COMPONENT_LIB_FILE(gid_File_Ucpext, ucpext) And move the entry to OOOLIBS? How we can handle this?
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=03a36ed0fb81088358d7cfc3068a7be9878f2f8b fdo#60949: Move more libs to OOOLIBS The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #3) > I saw some cases that we just have > SPECIAL_COMPONENT_LIB_FILE(gid_File_Ucpext, ucpext.uno) > Do we need to change this to > SPECIAL_COMPONENT_LIB_FILE(gid_File_Ucpext, ucpext) > And move the entry to OOOLIBS? Yes, the componentfile should be renamed along with the lib itself.
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=95f2f5f4d1a6d94788ea4e3905c25ddd69eb3d9b fdo#60949: Move the last libs to OOOLIBS The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Guys, there are only two lib in UNOLIBS_OOO: nulcanvas directx5canvas directx5 seems to be useless, after make a "git grep direct5canvas" it only returns the file Repository.mk. So I removed this entry. But, nullcanvas, it find a Library_nullcanvas at canvas/ dir, but there is nothing that references this in scp2... can I remove this canvas/Library_nullcanvas.mk and all references? Thanks since now!
(In reply to comment #7) > But, nullcanvas, it find a Library_nullcanvas at canvas/ dir, but there is > nothing that references this in scp2... can I remove this > canvas/Library_nullcanvas.mk and all references? > Yep, including the code - it serves as a boilerplate for new canvas implementations, but can do so just as well in the git history.
thbehrens, after a git grep nulcanvas I get this: marcos@jedi:~/gitroot/core$ git grep nullcanvas Repository.mk: nullcanvas \ canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_Library,nullcanvas)) canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_set_componentfile,nullcanvas,canvas/source/null/nullcanvas)) canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_use_external,nullcanvas,boost_headers)) canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_use_sdk_api,nullcanvas)) canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_use_libraries,nullcanvas,\ canvas/Library_nullcanvas.mk:$(eval $(call gb_Library_add_exception_objects,nullcanvas,\ canvas/Module_canvas.mk: Library_nullcanvas \ canvas/source/null/null_canvasbitmap.cxx:namespace nullcanvas canvas/source/null/null_canvasbitmap.hxx:namespace nullcanvas canvas/source/null/null_canvascustomsprite.cxx:namespace nullcanvas canvas/source/null/null_canvascustomsprite.hxx:namespace nullcanvas canvas/source/null/null_canvasfont.cxx:namespace nullcanvas canvas/source/null/null_canvasfont.hxx:namespace nullcanvas canvas/source/null/null_canvashelper.cxx:namespace nullcanvas canvas/source/null/null_canvashelper.hxx:namespace nullcanvas canvas/source/null/null_devicehelper.cxx:namespace nullcanvas canvas/source/null/null_devicehelper.hxx:namespace nullcanvas canvas/source/null/null_spritecanvas.cxx:namespace nullcanvas canvas/source/null/null_spritecanvas.cxx:COMPHELPER_SERVICEDECL_EXPORTS1(nullcanvas, nullcanvas::nullCanvasDecl) canvas/source/null/null_spritecanvas.hxx:namespace nullcanvas canvas/source/null/null_spritecanvashelper.cxx:namespace nullcanvas canvas/source/null/null_spritecanvashelper.hxx:namespace nullcanvas canvas/source/null/null_spritehelper.cxx:namespace nullcanvas canvas/source/null/null_spritehelper.hxx:namespace nullcanvas canvas/source/null/null_textlayout.cxx:namespace nullcanvas canvas/source/null/null_textlayout.hxx:namespace nullcanvas canvas/source/null/null_usagecounter.hxx:namespace nullcanvas canvas/source/null/nullcanvas.component:<component loader="com.sun.star.loader.SharedLibrary" prefix="nullcanvas" canvas/source/null/sprite.hxx:namespace nullcanvas What sources can I drop too? Thanks for the patience!
@Marcos: If I understand Thorsten correctly, "it can do so from the git history" means you can drop it as we have version control and someone interested in it can go back in time there to pick it up.
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1cd9b5d859a6468164b043b0fcaaf49c1907500c fdo#60949: Remove UNOLIBS_OOO The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #11) > Marcos Paulo de Souza committed a patch related to this issue. > Thx! :)
After https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=22e1a5b836b898298b6a5cfbaf1c82d9c3f08349 there is no more UNOLIBS_OOO in master, thanks
Marcos Paulo de Souza committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eb190f135dc8fd0c22d9b10bae3788b259fce91a fdo#60949: move last UNOLIBS_OOO to OOOLIBS The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript ) [NinjaEdit]