Closed
Bug 38061
Opened 24 years ago
Closed 22 years ago
mozilla/include obsolete? If so, cvs remove it
Categories
(SeaMonkey :: Build Config, defect, P3)
SeaMonkey
Build Config
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: norrisboyd, Assigned: cls)
References
Details
(Keywords: arch, Whiteboard: [driver:blizzard])
Attachments
(1 file, 15 obsolete files)
6.74 KB,
patch
|
bryner
:
review+
alecf
:
superreview+
tor
:
approval+
|
Details | Diff | Splinter Review |
Is the mozilla/include directory obsolete? I believe it is a remnant from Mozilla Classic. Certainly a lxr search on allxpstr indicates that it is not used.
You just don't know how much I would enjoy that....but there is still some code that uses at least nscore.h. We're probably going to have to cvs remove a file at a time to keep people from backsliding.
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → M18
The attached patch shows that we only use about 18 of the 101 header files in mozilla/include . In my previous comment, I meant xp_core.h, not nscore.h. xp_core.h contains many of the standard defines (XP_WIN, XP_MAC, XP_BEGIN_PROTOS) so I'm not sure if we'll ever be able to get rid of it. Of the remaining headers, a few of them were trimmed (via #ifdef 0) to remove unused functions and/or to stop them from dragging in other header dependencies. mailnews/mime also suffered some damage as it still had functions that took MWContext as an argument. The patch works under linux. Still needs to be tested under windows, mac & on the commercial side.
Comment 4•24 years ago
|
||
I would just like to say for the record is that the reason I see a lot of people including xp_core.h is because XP_WIN is NOT defined by the windows build. People include xp_core.h so they can have XP_WIN. Getting rid of xp_core.h and making people do stuff the right way would go a long way toward making the build more cross platform.
Comment 5•24 years ago
|
||
I say we should move the minimum amount of junk from xp_core.h to xpcom/base/nscore.h or some such place. How hard can that be? Then back off and nuke mozilla/include from orbit (it's the only way to be sure). /be
With only 1st degree burns to the tree, an updated version of the patch has been checked in. On win32 & linux, the current mozilla/include files which are still being used: csid.h intl_csi.h libi18n.h merrors.h minicom.h msgcom.h msgtypes.h net.h npapi.h npupp.h ntypes.h platform.h xlate.h xp_core.h xp_file.h xp_mem.h xp_path.h xp_regexp.h xp_str.h include/MANIFEST contains around 100 files. The only major difference in the mac include set are the ifdef XP_MAC chunks in include/net.h. Like mkaply pointed out, a good chunk of xp_core.h ifdefs can probably be removed just by adding -DXP_WIN to config/config.mak.
Comment 7•24 years ago
|
||
If someone has done the legwork to find out what other files include these old decrepit headers, please summarize here. Otherwise I'll go crazy with lxr. /be
Comment 9•24 years ago
|
||
Hi, I just had a look at include/intl_csi.h. It is only used for three functions, all implemented in mailnews/mime/src/oldi18n.c Should the functions INTL_GetCSIDocCSID, INTL_SetCSIDocCSID and LO_GetDocumentCharacterSetInfo get moved to mailnews/mime/src? Those functions are only accessed from mailnews/mime/src as well. Axel
Comment 10•24 years ago
|
||
Oh, darn spammers. me got confused, I had this done, and didn't realize. Patch to oldi18n.c get's attached, please test on other platforms, this was tested on solaris. This should make intl_csi.h go ^. Axel
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
Assignee | ||
Comment 13•24 years ago
|
||
*** Bug 14004 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 14•24 years ago
|
||
Can I get a mac buddy to verify that the mac can build if you remove all *.h from mozilla/include except: csid.h intl_csi.h libi18n.h merrors.h minicom.h msgcom.h msgtypes.h net.h npapi.h npupp.h ntypes.h platform.h shistele.h xlate.h xp_core.h xp_file.h xp_list.h xp_mem.h xp_path.h xp_regexp.h xp_str.h The test may be as simple as removing the other headers from mozilla/include/MANIFEST and doing a clobber build.
Assignee | ||
Comment 15•24 years ago
|
||
Thanks to bryner, we're down to 61 headers. Definitely not going to make it for M18, nominating for mozilla 0.9.
Keywords: arch,
mozilla0.9
Target Milestone: M18 → M19
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
looks good, bryner. sr=scc
Comment 18•24 years ago
|
||
Cc'ing mailnews reviewers for r= and sr= on bryner's patch. Who should review Axel's patch for intl_csi.h? /be
Comment 19•24 years ago
|
||
brendan: This patch was actually already checked in, sorry for not getting sr= marked in the bug. Also, the intl_csi.h patch is no longer relevant because jgmyers has removed the file entirely.
Comment 20•24 years ago
|
||
note to brendan, I've been reviewing bryner's mailnews patches.
Comment 21•23 years ago
|
||
Mmmm, cleanup. sr=shaver.
Comment 23•23 years ago
|
||
sr=brendan@mozilla.org, go bryner! /be
Comment 24•23 years ago
|
||
Assignee | ||
Comment 25•23 years ago
|
||
Comment on attachment 50352 [details] [diff] [review] get rid of reference to xp_file.h from nspr r=cls
Attachment #50352 -
Flags: review+
Comment 26•23 years ago
|
||
Comment on attachment 50352 [details] [diff] [review] get rid of reference to xp_file.h from nspr sr=sfraser
Attachment #50352 -
Flags: superreview+
Assignee | ||
Comment 27•23 years ago
|
||
Comment 28•23 years ago
|
||
Comment on attachment 50357 [details] [diff] [review] Remove some xpfile.h references from mailnews & layout sr=alecf
Attachment #50357 -
Flags: superreview+
Comment 29•23 years ago
|
||
Comment on attachment 50357 [details] [diff] [review] Remove some xpfile.h references from mailnews & layout r=bryner
Attachment #50357 -
Flags: review+
Comment 30•23 years ago
|
||
attachment 50357 [details] [diff] [review] is now checked in.
Comment 31•23 years ago
|
||
Comment on attachment 50357 [details] [diff] [review] Remove some xpfile.h references from mailnews & layout I've got another patch for this which I'll also attach.
Comment 32•23 years ago
|
||
Comment 33•23 years ago
|
||
rs=bienvenu on the msg send part of the xp_file patch.
Comment 34•23 years ago
|
||
We probably don't really need to edit xp_file.h if we're going to remove it soon...
Comment 35•23 years ago
|
||
eh, can't hurt, right? :)
Comment 36•23 years ago
|
||
Comment on attachment 52535 [details] [diff] [review] get rid of XP_File r=bryner on the nsMsgSendPart part of this patch
Attachment #52535 -
Flags: review+
Comment 37•23 years ago
|
||
Comment 38•23 years ago
|
||
Comment on attachment 53719 [details] [diff] [review] Remove XP_File usage from gfx/src/ps r=bryner
Attachment #53719 -
Flags: review+
Comment 39•23 years ago
|
||
Comment on attachment 53719 [details] [diff] [review] Remove XP_File usage from gfx/src/ps good god! sr=alecf
Attachment #53719 -
Flags: superreview+
Comment 40•23 years ago
|
||
Comment 41•23 years ago
|
||
Comment 42•23 years ago
|
||
I'm pretty sure the mork changes are safe unless we plan to start defining MORK_OBSOLETE sometime soon. The actual removal of the header needs to first be tested on the commercial build on all three platforms. (I can report that it's fine on Win32).
Comment 43•23 years ago
|
||
Comment on attachment 54032 [details] [diff] [review] buh bye r=cls
Attachment #54032 -
Flags: review+
Updated•23 years ago
|
Attachment #54030 -
Flags: needs-work+
Comment 44•23 years ago
|
||
If we're going to break MORK_OBSOLETE like that, then we should just remove it entirely. I think it may be better to just replace the XP_File wrapper defines with their underlying C counterparts (why they were wrapped to begin with is still a mystery to me).
Comment 45•23 years ago
|
||
Comment on attachment 54032 [details] [diff] [review] buh bye yay. sr=alecf
Attachment #54032 -
Flags: superreview+
Comment 46•23 years ago
|
||
Comment on attachment 54030 [details] [diff] [review] get rid of xp_file references from mork let's make sure MORK_OBSOLETE doesn't refer to anything else besides xp_file. I would guess we just want to kill it. I doubt it even works.
Comment 47•23 years ago
|
||
MORK_OBSOLETE won't be resurrected. It was probably left in there from when mork was developed standalone with its own test harness. That's my guess, anyway.
Comment 48•23 years ago
|
||
Comment 49•23 years ago
|
||
Comment on attachment 54382 [details] [diff] [review] completely remove MORK_OBSOLETE and MORK_ALONE sr=alecf
Attachment #54382 -
Flags: superreview+
Comment 50•23 years ago
|
||
*** Bug 63834 has been marked as a duplicate of this bug. ***
Comment 51•23 years ago
|
||
The files mozilla/netwerk/dns/src/unix-dns.c mozilla/include/unix-dns.h appear to be unreferenced.
Updated•23 years ago
|
Keywords: mozilla1.0
Comment 52•23 years ago
|
||
Comment on attachment 54382 [details] [diff] [review] completely remove MORK_OBSOLETE and MORK_ALONE r=bienvenu
Attachment #54382 -
Flags: review+
Comment 53•23 years ago
|
||
latest patch checked in.
Comment 54•23 years ago
|
||
It appears we can remove xp_file.h with no problems. Successfully built Linux and Win32 (moz and ns) and mach-o mozilla with the file removed.
Comment 55•23 years ago
|
||
sr=alecf good luck and godspeed.
Comment 56•23 years ago
|
||
You need to test building Mac commercial before removing this file.
Comment 57•23 years ago
|
||
jag reports that mac commercial builds fine without this file
Comment 58•23 years ago
|
||
a=brendan@mozilla.org for the 0.9.9-frozen trunk -- free at last! Thanks, /be
Blocks: 122050
Keywords: mozilla0.9.9+
Comment 61•23 years ago
|
||
Can I get r= to remove the two files mentioned in comment #51?
Blocks: 122050
Comment 62•23 years ago
|
||
r=alecf on the removal of unix-dns.h and unix-dns.c
Comment 63•23 years ago
|
||
sr=darin on the removal of unix-dns.h and unix-dns.c
a=dbaron for trunk checkin of the removal of unix-dns.h and unix-dns.c
Comment 65•23 years ago
|
||
Chris, we're nearing the end of 0.9.9 and want to push out the Milestone ASAP. Can you make these changes ASAP and pull this bug off of the 122050 dependency list if it needs to stay open after the 0.9.9 checkins. Thanks.
Comment 66•22 years ago
|
||
The majority of this patch is replacing the xp_core.h include with prtypes.h & prlog.h and search-n-replace on the xp_mem.h & xp_str.h macros. There are a few of questionable bits. 1) XP_BEGIN_PROTOS/XP_END_PROTOS were replaced by PR_BEGIN_EXTERN_C/PR_END_EXTERN_C. This moved some deps from xp_core.h to prtypes.h. 2) The XP_Bool type detection was completely thrown out. Added a 'typedef int XP_Bool' to nsPostscriptObj.h in the same fasion as libreg & movemail. 3) NULL & nil are no longer defined. 4) Removed all of the PA_LOCK/PA_UNLOCK stuff along with the XP_Block stuff. 5) Copied the _INT16,_INT32 defines into npapi.h since it's the only place that requires it. 6) Moved the PUBLIC, PRIVATE & MODULE_PRIVATE defines into nsComObsolete.h One question: How does NOT_NULL work in DEBUG builds?
Attachment #8720 -
Attachment is obsolete: true
Attachment #11573 -
Attachment is obsolete: true
Attachment #11580 -
Attachment is obsolete: true
Attachment #21387 -
Attachment is obsolete: true
Attachment #27494 -
Attachment is obsolete: true
Attachment #50352 -
Attachment is obsolete: true
Attachment #50357 -
Attachment is obsolete: true
Attachment #52535 -
Attachment is obsolete: true
Attachment #53719 -
Attachment is obsolete: true
Attachment #54030 -
Attachment is obsolete: true
Attachment #54032 -
Attachment is obsolete: true
Attachment #54382 -
Attachment is obsolete: true
Comment 67•22 years ago
|
||
I need a mac buddy. I already verified that the patch works on linux & win32 on both moz & ns trees.
Comment 68•22 years ago
|
||
bugscape 12706
Comment 69•22 years ago
|
||
I verified that this patch works on mac, linux & win32. Can I get some r/sr love? Anyone? Anyone?
Attachment #75356 -
Attachment is obsolete: true
Comment 70•22 years ago
|
||
Comment on attachment 76139 [details] [diff] [review] Same with mac updates rs=alecf
Attachment #76139 -
Flags: superreview+
Comment 71•22 years ago
|
||
Comment on attachment 76139 [details] [diff] [review] Same with mac updates Looks good to me, but can we reomve xp_mcom.h's include here: +++ dbm/include/mcom_db.h 2002/03/26 02:53:26 @@ -240,9 +240,9 @@ #include "xp_mcom.h" #define O_ACCMODE 3 /* Mask for file access modes */ #define EFTYPE 2000 -XP_BEGIN_PROTOS +PR_BEGIN_EXTERN_C int mkstemp(const char *path); -XP_END_PROTOS +PR_END_EXTERN_C #endif /* MACINTOSH */ In for a penny... /be
Attachment #76139 -
Flags: review+
Comment 72•22 years ago
|
||
That include is wrapped in a macintosh ifdef and the mac needs xp_mcom.h to get the prototype for strdup. Anyone know in which codewarrior header strdup is actually declared?
Updated•22 years ago
|
Attachment #76139 -
Flags: approval+
Comment 73•22 years ago
|
||
Attachment #76139 -
Attachment is obsolete: true
Comment 74•22 years ago
|
||
It turns out that we weren't using any of the defines from xpassert.h, xp_debug.h or xp_trace.h in any active code. I translated a few of the ifdef'd out XP_ASSERTs into NS_ASSERTIONs. Minicom.h isn't used either but it's still referenced by some of the stub-java code so I'm not sure if it can be cvs removed just yet.
Attachment #76671 -
Attachment is obsolete: true
Comment 75•22 years ago
|
||
Comment on attachment 76983 [details] [diff] [review] Previous + get rid of xpassert.h, xp_debug.h & xp_trace.h r=bryner, but please make sure the ns tree builds as well.
Attachment #76983 -
Flags: review+
Comment 76•22 years ago
|
||
Comment on attachment 76983 [details] [diff] [review] Previous + get rid of xpassert.h, xp_debug.h & xp_trace.h sr=alecf
Attachment #76983 -
Flags: superreview+
Comment 77•22 years ago
|
||
Comment on attachment 76983 [details] [diff] [review] Previous + get rid of xpassert.h, xp_debug.h & xp_trace.h a=tor
Attachment #76983 -
Flags: approval+
Comment 79•22 years ago
|
||
Removing adt1.0.0. you can check in with Drivers approval.
Keywords: adt1.0.0
Comment 80•22 years ago
|
||
Putting back adt1.0.0 keyword and asking for info. Will the user notice any of these changes? For example, I see there are changes to mailnews. Is there any possibility that the code will behave differently than it does now? What's the risk associated with this and is there any benefit to users?
Keywords: adt1.0.0
Comment 81•22 years ago
|
||
There are no end-user visible changes in these patches. The purpose of the changes are to remove obsolete code that we no longer support and have replaced wholesale. The mailnews code that is changed is either a) commented out b) wrapped in a debug ifdef or c) wrapped in some other ifdef that we don't compile in (nothing broke when the 5 files in question were replaced wholesale with an #error clause) I made the macro changes anyway so that the code doesn't mysteriously break when someone tries to enable one of those disabled ifdefs.
Comment 83•22 years ago
|
||
Oops. Restoring ADT signature and opening new bug (maybe) for the last 3 remaining headers per Jud.
Comment 84•22 years ago
|
||
I'm not sure if this was checked in. If it wasn't, removing the adt1.0.0+. If it was, please add the fixed1.0.0 keyword.
Keywords: adt1.0.0+
Updated•22 years ago
|
Keywords: fixed1.0.0
Comment 85•22 years ago
|
||
v fixed. is there a new bug number for those last few header files?
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•