Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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.