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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
