gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] libtla


From: Tom Lord
Subject: Re: [Gnu-arch-users] libtla
Date: Fri, 27 Feb 2004 19:23:54 -0800 (PST)


    > From: Brian May <address@hidden>

    >     Tom> I'm glad Jeremy replied to your original message because I seem 
to
    >     Tom> have accidentally deleted it while catching up with mail.

    > Would you prefer I CC you mails as appropriate? Generally I don't for
    > mailing list posts, some people get annoyed :-(.

No...   your message just came at a problematic time and, anyway --
there'll always be a Jeremy or three to pick up things I miss.


    >     Tom> I haven't looked at it yet.   If you want to declare that you've 
hit a
    >     Tom> milestone and that I should look at it as a merge request I will.

    > No, not there yet...

Ok, well if you're stuck on something with questions this is the right
place to ask.


    >     Tom> So: is your work on step 2a ready for merging?  Have you used 
`nm' and
    >     Tom> some shell tools to verify that the call-graph layering worked 
out
    >     Tom> correctly?

    > I am unfamiliar with using nm to check the call graph in this manner,
    > my checks are a bit more primitive, but hopefully accurate(?).


This is a fun kind of "old school unix" exercise but not critical (see
below).  For the record: Given a build directory for your modified
tla, you can run nm on the .o files in various subdirs to find out
what exported symbols are defined ("D") where and which are referenced
("U") where.  So, arch_valid_archive_name might show up as "D" in
src/tla/libarch-utils and as "U" in src/tla/libarch-cmds.  A few lines
of awk, perl, python -- or just a few minutes of futzing around with
grep and sort and so forth -- and you can make sure that nothing in
libarch-utils calls out to libarch-cmds.  (Or, alternatively, find out
the cases where it does that need some thought about how to fix that.)

But it's not the only way to do it and it doesn't sound like you
should bother.  See the next:




    >     Tom> It would be helpful if you could list which files and functions 
you've
    >     Tom> put into libarch-utils.

    > Ok, my "incomplete" checks so far are:

    > * it compiles and links

    > * I have checked that nothing in libarch-utils/* includes any include 
files
    > from libarch-cmds/*:

That's a good sign.  If you are using gcc, compile with -Wall.   If
libarch-utils is calling out to libarch-cmds, you should get some
"undeclared function" warnings.



    > >tla inventory --source libarch-utils | xargs grep 'libarch-cmds\/'
    > [ no output ]

    > * I have checked that nothing in libarch/* includes any include files
    > from libarch-cmds/*:

    > >tla inventory --source libarch | xargs grep 'libarch-cmds\/'
    > [ no output ]

That all sounds great.   Other than maybe running the -Wall check if
you have a chance, that's just as good as my old-school `nm' technique.


    > libarch/ancestry.h           libarch/editor.h
    > libarch/archive.h            libarch/exec.h
    > libarch/archive-mirror.h     libarch/hooks.h
    > libarch/archive-pfs.h        libarch/libraries.h
    > libarch/archives.h           libarch/missing.h
    > libarch/archive-snapshot.h   libarch/pfs-dav.h
    > libarch/archive-version.h    libarch/pfs-fs.h
    > libarch/cached-inventory.h   libarch/pfs-ftp.h
    > libarch/changeset-report.h   libarch/pfs.h
    > libarch/changeset-utils.h    libarch/pfs-sftp.h
    > libarch/chatter.h            libarch/pfs-signatures.h
    > libarch/cmd.h                libarch/proj-tree-lint.h
    > libarch/cmdutils.h           libarch/sftp.h
    > libarch/copy-project-tree.h  libarch/whats-new.h
    > libarch/diffs.h

    > I am uncertain how to classify these files, except I think all of them
    > could go into libarch-utils, as far as I can tell, nothing here depends
    > on libarch-cmds.

I think these go in -utils:

  chatter.[ch]
  editor.[ch]
  exec.[ch]
  hooks.[ch]

and the rest in -cmds.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]