Hi David,
On Wed, 2013-03-06 at 08:08 +0100, David Ostrovsky wrote:
On Tue Mar 5 Michael Meeks wrote:
>I had a quick hack at the:
> make module-deps
Thank you! After looking into it i thnk, that it needs some tweaks
before it can be merged ;-)
;-) FWIW - I fixed the horror thinko / performance problems in the
graph collapsing so it is now ~instant.
(a) you named it module-deps, but it is library-deps for now.
True of course; feel free to rename it to your taste :-) it sounds like
the tool has a new maintainer in it's first day - which is great: I
signed up only for a prototype :-)
Well may be we want library-deps too, but to be a module dep it
should induce module name from the library name.
Sure - as you say, that's not too hard to do; we could collapse the
existing graph quite nicely and quickly to get the deps out of it; and
produce something even neater and more readable :-) Of course, adding
more parameters and options to the script would be nice - the need to
call it via the Makefile to get the environment setup is not that cool
for extensibility I think.
(b) some subtle differencies to hand made dmake build module dependency
list:
Ah - well, it's always nice to find bugs :-)
Compared to the dmake build module dependency list it seems not to say
the whole truth:
cat svx/prj/build.lst
sx svx : sfx2 oovbaapi DBCONNECTIVITY:connectivity xmloff
linguistic jvmfwk avmedia drawinglayer editeng LIBXSLT:libxslt officecfg
and your result:
grep "svx \\-" module-deps.graphviz
svx -> svxcore;
The dependency to connectivity is missing. For one there is no such a
lib (see (a)) , for another
there is no explicit dependency to any connectivity library exist (or am
i missing something?):
gnumake dumps:
LibraryDep: Library_svx links against basegfx sb comphelper cppuhelper
cppu drawinglayer editeng i18nisolang1 sal sfx sot svl svt svxcore tk tl
ucbhelper utl vcl xo xmlscript
LibraryDep: links against icuuc
LibraryDep: Library_svxcore links against avmedia basegfx sb comphelper
cppuhelper cppu drawinglayer editeng fwe i18nisolang1 lng sal salhelper
sax sfx sot svl svt tk tl ucbhelper utl vcl xo
but a quick:
git grep 'include.*connectivity'
Shows that:
svx/source/form/
pieces include connectivity.
But - as you say - they do not link to the dbtools library that we
would expect to implement those symbols.
Even more curiously ldd on the libsvxlo.so and libsvxcorelo.so in my
install shows no dependency on libdbtoolslo.so - as I would expect :-)
Similarly the object files export no symbols that are in the dbtools
namespace - but perhaps I'm looking at the wrong thing :-)
And still we have this dependency svx -> connectivity as mentioned in
svx/prj/build.lst
and as this include implies:
grep "<connectivity" svx/inc/svx/dbtoolsclient.hxx
#include <connectivity/virtualdbtools.hxx>
Yep - interesting; so of course - there is a set of include level
dependencies there - that (if we wanted to find them) we would need to
parse the full:
make -n -p
output. Having watched that take many 10's of minutes to generate and
not complete - producing some staggering log-file ;-) I was rather
tempted to give that a miss. Perhaps it'd be easier to post-process our
(reduced) library dependency files with some lint tool.
Anyhow - AFAICS there is something odd about svx's use of connectivity/
it does indeed appear not to produce a library linkage requirement.
Which is interesting in itself ;-)
ATB !
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.