42026 - Patches to build standalone XPConnect on Windows NT

Status: RESOLVED FIXED

(Core :: XPConnect, enhancement, P3)

Description

[Mark G. Adams]

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

Comment 1

[Mark G. Adams]

Attachment: Add pull_xpconnect and build_xpconnect to client.mak

Comment 2

[Mark G. Adams]

Attachment: Disable rest of 'echo' test due to pulling in outside interfaces

Comment 3

[Mark G. Adams]

Attachment: Define XPCOM_STANDALONE and XPCONNECT_STANDALONE if required in config/config.mak

Comment 4

[Mark G. Adams]

Attachment: Don't try to make liveconnect when XPCONNECT_STANDALONE

Comment 5

[Mark G. Adams]

Attachment: Disable properties test due to pulling in external interfaces

Comment 6

[cls]

jband is on sabbatical.

Comment 7

[John Bandhauer]

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.

Comment 8

[Mark G. Adams]

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.

Comment 9

[Mark G. Adams]

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

[John Bandhauer]

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

Comment 11

[John Bandhauer]

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

[Daniel (Leaf) Nunes]

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?

Comment 13

[Mark G. Adams]

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

[John Bandhauer]

Attachment: my revision of Mark's patches (all in one file)

Comment 15

[John Bandhauer]

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.

Comment 16

[Mark G. Adams]

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

[John Bandhauer]

patches checked in.