Patches to build standalone XPConnect on Windows NT

RESOLVED FIXED

Status

()

P3
enhancement
RESOLVED FIXED
19 years ago
18 years ago

People

(Reporter: madams, Assigned: leaf)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

19 years ago
The following are the patches required to build a standalone XPConnect on
MS-Windows NT. Note that with minor additions to client.mak modelled after my
additions for xpconnect, you could use this to build a standalone XPCom package
on NT as well.

Note that these patches depend on the patches in bug 42024 (for building
standalone XPConnect on Unix).

Build procedure after these patches have been applied:
         cvs co mozilla/client.mak
	 cd mozilla
	 nmake /f client.mak pull_xpconnect
	 nmake /f client.mak build_xpconnect

Files:
1) client.patch- add pull_xpconnect, build_xpconnect and clobber_xpconnect rules
to client.mak
2) components.patch
- surround anything to do with the 'echo' test with #ifndef
XPCONNECT_STANDALONE, since it pulls in the external timer interfaces
3) config.patch
- add the *_STANDALONE defines to CFLAGS if requested in config/client.mak
4) jsmakefile.patch
- don't try to make liveconnect when building XPCONNECT_STANDALONE
5) props.patch
- surround most of xpcom/tests/PropertiesTest.cpp with #ifndef
XPCONNECT_STANDALONE since it pulls in external interfaces

Patches to be attached shortly
(Reporter)

Comment 1

19 years ago
Created attachment 9877 [details] [diff] [review]
Add pull_xpconnect and build_xpconnect to client.mak
(Reporter)

Comment 2

19 years ago
Created attachment 9878 [details] [diff] [review]
Disable rest of 'echo' test due to pulling in outside interfaces
(Reporter)

Comment 3

19 years ago
Created attachment 9879 [details] [diff] [review]
Define XPCOM_STANDALONE and XPCONNECT_STANDALONE if required in config/config.mak
(Reporter)

Comment 4

19 years ago
Created attachment 9880 [details] [diff] [review]
Don't try to make liveconnect when XPCONNECT_STANDALONE
(Reporter)

Comment 5

19 years ago
Created attachment 9881 [details] [diff] [review]
Disable properties test due to pulling in external interfaces

Comment 6

19 years ago
jband is on sabbatical.
Assignee: jband → leaf
Status: UNCONFIRMED → NEW
Depends on: 42024
Ever confirmed: true

Comment 7

19 years ago
What is the status of getting this stuff checked in?

I don't think it makes sense to completely disable all of the echo test 
component just because one method can not be functionally implemented. The echo 
components is the *main* xpconnect test component. It would be better to simply 
disable the functionality of the part that relies on the timer code. Then, most 
of the test would still work.
(Reporter)

Comment 8

19 years ago
Chris Seawood just checked in the patches for building xpconnect standalone on
UNIX (bug 42024), which was required for this set of patches. Thus, they should
be ready to go.

As for disabling the echo test, I simply took the fastest route to getting the
stuff to build usably. Definitely, that test should be modified to either
selectively compile the outside part, or remove that part entirely. This was
however meant to be a rough cut which could then be refined if desired.
(Reporter)

Comment 9

19 years ago
What's the status with these patches - is the only holdup the echo test? If so,
I'll take the 5 or so minutes needed to change that part of the patch. It'd be
really nice to get this set of patches merged in.

//Mark

Comment 10

18 years ago
leaf, this is mostly build system change. What say you?

Comment 11

18 years ago
For the pull_xpconnect: target in client.mak it would make sense to use our 
named cvs modules rather than pull all in the directories listed. Specifically, 
the checkout of 'mozilla/js' gives you a lot of stuff you don't need. I don't 
seem to have access to CVSROOT/modules to know what is in there.

We could ask leaf to make a module of exactly all of what you need, or find out 
what modules exist and leverage some of them, or change your patch to limit it 
to -l in mozilla/js and everything under js/src. There might be more that is 
also required?

Comment 12

18 years ago
If we really care about backward compatibility, we're better off not using a
modules file, but rather using some kind of script that lists the directories to
checkout. I will add cvs modules at the request of module owners, even though it
is against my counsel. 

The patches to the build system look good, r=leaf; are there plans for similar
work on unix? Or, heaven forbid, mac?
(Reporter)

Comment 13

18 years ago
Equivalent build for standalone XPConnect's already done and checked in for Unix
(see bug 24024). Since I don't have access to a Mac, I'm afraid I can't help
there.

//Mark

Comment 14

18 years ago
Created attachment 11514 [details] [diff] [review]
my revision of Mark's patches (all in one file)

Comment 15

18 years ago
My patch pulls all Mark's stuff together into one patch file and adds some 
changes...

1) was not building in mozilla/include
2) narrowed the cvs co directories to not pull ALL under mozilla/js
3) build and register nsEcho with timer stuff #ifdefed out. nsEcho is the 
core test for xpconnect.

FWIW, I think it is a mistake to explicitly set XPCOM_STANDALONE and 
XPCONNECT_STANDALONE in client.mak. Instead you should tell users to set then 
(via a batch file or whatever) before they start. By magically setting then here 
people are less likely to set them more globally, so if they later cd to one of 
the subdirs and do a "nmake -f makefile.win" some unexpected stuff will happen. 

I left the 'set' loine in my patch, but I'm included to remove them before 
checking in. comments?

I'll apply these patched to a full tree and make sure I didn't break anything.
(Reporter)

Comment 16

18 years ago
Patch looks good from this end after a quick once-over. As for defining the
*_STANDALONE vars, I agree it makes sense to have the user define them manually,
and that should be included in the documentation for building this stuff
standalone on NT.

Comment 17

18 years ago
patches checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.