15780 - xpcom specified too specifically in cvs modules file

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Chris McAfee]

xpcom currently shows up like this in the modules file:

  mozilla/xpcom/.cvsignore
  mozilla/xpcom/Makefile.in mozilla/xpcom/makefile.win
  mozilla/xpcom/appshell mozilla/xpcom/base mozilla/xpcom/build
  mozilla/xpcom/components mozilla/xpcom/doc mozilla/xpcom/ds
  mozilla/xpcom/io mozilla/xpcom/macbuild mozilla/xpcom/proxy
  mozilla/xpcom/reflect mozilla/xpcom/sample mozilla/xpcom/threads
  mozilla/xpcom/tests mozilla/xpcom/tools !mozilla/xpcom/tools/xpidl
  mozilla/xpcom/typelib

why so complicated?  Why can't we just specify:

  mozilla/xpcom

Comment 1

[Suresh Duddi (gone)]

I know there were some directories that were obsoleted as part of xpcom2.0
landing. Hence the list.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

So can we "cvs remove" those dirs and simplify as mcafee suggests?

Comment 3

[Suresh Duddi (gone)]

I thought even if you cvs remove those directories, these will exist with no
files. There is no real way to remove a directory.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Sure, they exist in the repository, but they don't get pulled into people's
trees on fresh checkouts.  Additionally, "cvs {co,update} -P", such as is done
by client.mk causes directories that are empty in the Repository to be pruned in
your local copy of the tree.  Technically, you don't really "cvs remove" the
directories, I don't think, but as long as you "cvs remove" all files below, CVS
should behave as described above with no special treatment.

Comment 5

[Suresh Duddi (gone)]

Reassigning to leaf. I am happy as long as things keep working.

Comment 6

[Chris Yeh]

mass re-assign of all bugs where i was listed as the qa contact

Comment 7

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 8

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 9

[Daniel (Leaf) Nunes]

I think we pull with -P in most cases now, which prunes empty directories, i'll 
check to see that the directories not included in the current modules list are 
empty (that is, contain only cvs removed files), and change the modules file to 
include only xpcom/

Comment 10

[Daniel (Leaf) Nunes]

there are just a few directories that we don't pull that have code in them:
xpcom/libxpt/
and 
xpcom/remote
jband, what say you to removing the stuff in xpcom/libxpt? Is it still in use at 
all?

Comment 11

[John Bandhauer]

[here's what I replied in email to leaf]

AFAICT the only files that remain are the two html files in
xpcom/libxpt/xptcall. Do you see others? These were left behind
when xptcall was moved because (early on) there were published
links to these documents in the source repository via lxr. I'm
not sure this matters anymore. I cared at the time the documents
were moved. But, the files left behind have been telling people
to update their links for a year and a half now. I'm OK with you
whacking them if it matters to you.

http://lxr.mozilla.org/mozilla/source/xpcom/libxpt/xptcall/porting.html
http://lxr.mozilla.org/mozilla/source/xpcom/libxpt/xptcall/status.html

Comment 12

[Daniel (Leaf) Nunes]

with that info, i've modified the modules file to pull everything under xpcom/ 
for SeaMonkeyCore. resolving fixed.