Re: [Libreoffice] module dependencies. a little tools to display them

On Sun, Apr 24, 2011 at 8:59 PM, Kohei Yoshida <kohei.yoshida@gmail.com> wrote:
> On Sun, Apr 24, 2011 at 8:55 PM, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
>
> > PS: yeah, I know. I probably re-invented the wheel... kohei's python
> > program to generate the nice little dep picture probably could have
> > done the work.
>
> Yes, mine already does that.  It has a single module mode that lets
> you dump dependency info for individual modules.

not quite:  your module either dump it all as a pair of parent/child
or dump one-level up and down of a given module
I need all up from a given module...
for example with svx mine give: (-u -p svx)
svx
  + xmlsecurity
     + postprocess
        + packimages
           + instsetoo_native
              + testgraphical
              + smoketestoo_native
  + writerfilter
     + sw
  + vbahelper
     + tail_build
     + scripting
     + sc
  + starmath
  + sd
  + oox
  + lotuswordpro
  + formula
     + reportdesign
  + forms
  + filter
     + desktop
  + extensions
  + dbaccess
  + cui
  + chart2
  + basctl

the python program give: (grep filtering lines where svx is on the left)
basctl:svx
chart2:svx
cui:svx
dbaccess:svx
desktop:svx
extensions:svx
filter:svx
forms:svx
formula:svx
lotuswordpro:svx
oox:svx
sc:svx
sd:svx
starmath:svx
sw:svx
vbahelper:svx
writerfilter:svx
xmlsecurity:svx

So for instance I miss the fact that scripting and reportdesign depend
(indirectly) on svx ...
That being said, I'm sure your python could have been taught to do
that... my point being that it does not 'already do that'.

> > But 1/ I could not find the source,
>
> It's in the build repository, under scratch/build-analysis-tools,
> named check-deps.py.

That's why I couldn't find it :-) I haven't been in the 'build' repo
in months... I actually had to dig to even find one on my machine :-)

> 2/ I don't know
> > python and learning it would have taken me more time than writing a
> > small C-program :-)
>
> It's a bit disappointing.
Sorry...

>  That will only give you a short-term gain.
> We write quite a few tools in python in this project, so there is a
> benefit to learning python.
There are plenty of stuff to learn, more than I will ever be able
to... so I have to choose my battle.
Here I just needed to quickly scratch an itch, not turn it into a project....

>  Plus, for tasks such as this, we are much
> better off writing tools in scripting languages, either perl or
> python.  C is over-kill for stuff like this.

Sure... although over-kill is a bit strong. Amusingly these 2 programs
have exactly the same number of lines (383) :-)

Norbert