The fpicker/ Library_fpicker.mk contains only a single file and there is no need for it to live inside fpicker - it produces a ridiculously small standalone library that could easily live ~anywhere else. It should be moved into vcl/ inside vcl/source/components NB. please use 'git mv' and then git commit immediately to retain history. We should re-work: SvtMiscOptions().UseSystemFileDialog() to use a direct configmgr access via sberg's nice new compiled-in API of that single setting; officecfg/registry/data/org/openoffice/Setup.xcu: <it>/org.openoffice.Office.Common/Misc/UseSystemFileDialog</it> via. bool officecfg::Office::Common::Misc::UseSystemFileDialog::get() etc. And we should cleanup all the horror RTL_CONSTASCII_USTRINGPARAM() mess at the same time - kill the fpicker library, and move the component file across: cat fpicker/source/generic/fpicker.component and merge it into the VCL component file. Thanks ! :-)
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Maybe fileaccess module is another candidate for this bug? marcos@jedi:~/gitroot/core$ ls -R fileaccess/ fileaccess/: Library_fileacc.mk Makefile Module_fileaccess.mk README source fileaccess/source: fileacc.component FileAccess.cxx This have just one file for this module,
yes; sounds like a good plan :-) reducing that madness would be wonderful.
I'm in the right direction here? https://gerrit.libreoffice.org/#/c/6288/
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=b538fc543ecfbafef94b15ef068890c22d7f2218 fdo#60698: Move fileaccess module to ucb 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.
Removing comma from whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Fpicker uses XComponentContext when creating the instance, while inside svtools ::cppu::createOneInstanceFactory it needs a XMultiServiceFactory... What can I do in this case?
(In reply to comment #7) > Fpicker uses XComponentContext when creating the instance, while inside > svtools ::cppu::createOneInstanceFactory it needs a XMultiServiceFactory... Note that svt_component_getFactory (svtools/source/uno/miscservices.cxx) already has an else branch that uses cppu::component_getFactoryHelper on a cppu::ImplementationEntry array s_aServiceEntries, so you can merge g_entries from fpicker/source/generic/fpicker.cxx into it.
(In reply to comment #8) > (In reply to comment #7) > > Fpicker uses XComponentContext when creating the instance, while inside > > svtools ::cppu::createOneInstanceFactory it needs a XMultiServiceFactory... > > Note that svt_component_getFactory (svtools/source/uno/miscservices.cxx) > already has an else branch that uses cppu::component_getFactoryHelper on a > cppu::ImplementationEntry array s_aServiceEntries, so you can merge > g_entries from fpicker/source/generic/fpicker.cxx into it. Thanks Stephan! https://gerrit.libreoffice.org/#/c/6436/ At least it don't gave me any error when linking, strange don't you think? But, there is another libs that we could merge?
I saw a lot of very small filters inside filter module: -rwxrwxr-x 1 marcos marcos 168K Oct 30 13:06 libitglo.so -rwxrwxr-x 1 marcos marcos 158K Oct 30 13:06 libipxlo.so -rwxrwxr-x 1 marcos marcos 156K Oct 30 13:06 libiralo.so -rwxrwxr-x 1 marcos marcos 155K Oct 30 13:06 libipblo.so And a lot of others inside filter module. But, it seems that this is used inside VCL: ImpFilterLibCacheEntry::GetImportFunction Do you think this can be unified into an bugger library, of all these small filters? As they're so small, and it seems they're used inside the same library.
I imagine the idea is to save memory, but on any modern machine I suspect the shlib overhead, and the linking cost of that makes that not worthwhile. Of course - that is -assuming- that running 'ldd' on each of those shows that they have the same shared library dependencies. Clearly it needs a lot of testing - I -hope- we have at least one (trivial) test image per file-format in git, and a unit test for loading it - if not, that is something we should add here before re-factoring that I think. Anyhow - thanks for poking at 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=b40ffd288baf6dc5989cc09c5b5007eee97dd1bf fdo#60698: Move generic fpicker to svtools 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=3a009c427fc04c0a1a100f5f04516cedd1f6f118 fdo#60698: Merge all libs of io... 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.
Nice work ! it all helps :-) having said that - I guess really we want to move to enable --enable-merge-libs=yes by default I suppose which then compiles a lot of these into a single library anyway :-) But - either way, all these tiny fragments (if they don't break dependencies) waste linking time and RAM to load/link them - so thanks !
The io module was a suggestion by Stephan! And yes, I'll try to look for more cases like this :) Thanks a lot for helping!
It seems that in scripting module we have 6 libs that are used in the same conditions inside Repository.mk. They just link to some libs in some cases, but most of the depencies are equal. I'll try to make some prototyping and see what happens :)
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=668d6ada160438c396849a8309864f5fd33f33ac fdo#60698: Unify spl and spl_unx 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=1c3d51fd6826fbc7d447243d40fcd351ad47ae84 fdo#60698: Merge tvhlp1 into ucpchelp1 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=35c1d6f7617087c18b94e03ec9281c995e6d9e55 fdo#60698: Merge hatchwindowfactory into svt 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=eebc1e9a8a5c7fd04b795c62791a70eed65995e4 fdo#60698: Merge fastsax and sax_shared into expwrap 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! After sending my patch about animcore, I saw that evtatt(eventattacher) just have one file... What's the best library to hold this implementation? Maybe basic? By removing all these small libs and dirs, maybe some newcomers will don't be scaned of the size of libreoffice project :)
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=692c724f5e71f685c269085983828e7539274ecb fdo#60698: Merge odbcbase into odbc 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.
And about xmlreader library? It just have 3 files... where we can put this? And this module don't have a component file, so this would be easy to merge...
(In reply to comment #23) > And about xmlreader library? > > It just have 3 files... where we can put this? xmlreader is used by both the URE and LO layers, but is not part of the URE stable interface, so there is no obvious other library to merge it into.
The original single file library is now fixed -> closing the Easy Hack =) Thanks for the great work !
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicCleanup ) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]