Afaik, right now there is only wince-arm in the build config platform list. We'd like to differentiate between wince-arm and winmo-arm in name at the very least. We can currently work around this because fennec is on winmo and firefox is on wince, but there have been rumblings about fennec on wince and renaming fennec to firefox. Beyond those things, putting 'wince' in the winmo binaries can be confusing.

I don't understand this bug. What's the "build config platform list"? Are you saying that in our configure script we should treat windows CE and windows mobile as different targets (which would end up meaning different OS_ARCH values in our build system)? That doesn't sound ideal. Windows mobile is in fact based on a Windows CE kernel.

Windows Mobile is based on Windows CE, but they're not compatible. What we end up with is fennec.*.wince-arm.* and firefox.*.wince-arm.*, but they are built for two different platforms. There are plans to rename fennec to firefox, at which point we will have firefox.*.wince-arm.* and firefox.*.wince-arm.*, which are difficult to differentiate.

So you're only worried about the filenames? That's easy enough to fix at packaging time.

That's my main concern, yes. Also, are things like nightly updates affected by this setting? If there really isn't anything else that's affected other than the binary filename, I'm fine with just fixing that.

https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml Having WinCE and WinMo builds both claiming to be WINCE_arm-msvc for BUILD_TARGET could well be a problem. Relying on the BUILD_ID to be unique isn't that great, and OS_VERSION isn't used for anything in AUS2 except not updating deprecated releases.

I'm not sure that the internal product name for updates and other things should be Firefox, regardless of what the marketing/public name is. It's not the same "product" from a code perspective, which is what updates and similar things care about.

This also isn't just a wince-specific problem; all of http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/ presumably will clash with firefox builds if it's renamed to firefox and takes the firefox version number.

Does (In reply to comment #6) > I'm not sure that the internal product name for updates and other things should > be Firefox, regardless of what the marketing/public name is. It's not the same > "product" from a code perspective, which is what updates and similar things > care about. Yeah. I'm not sure what this means specifically though. Does it mean everything branding-wise says Firefox, but you're launching fennec.exe? That would be easiest for us, definitely, but might be confusing to the user. However, agreed, having multiple binaries named Firefox that have completely different UIs can be confusing in general.

(In reply to comment #8) > Does it mean everything branding-wise says Firefox, but you're launching > fennec.exe? That would be easiest for us, definitely, but might be confusing > to the user. If it was purely up to me, this sounds like the best approach; confusing a little, sure, though the cases where the user will launch the actual binary is pretty rare. There also might well be places where it's valid to have both fennec and firefox installed (e.g. think of a netbook that can transform into a tablet), and we don't want them to clash.

Ok, per the Mobile meeting it sounds like the binary name will remain Fennec, which does simplify things. There were rumblings at some point of putting Fennec on WinCE devices (as recently as comment #9 :), which would necessitate differentiating the two platforms (winmo vs wince).

(In reply to comment #9) > (In reply to comment #8) > > Does it mean everything branding-wise says Firefox, but you're launching > > fennec.exe? That would be easiest for us, definitely, but might be confusing > > to the user. > > If it was purely up to me, this sounds like the best approach; confusing a > little, sure, though the cases where the user will launch the actual binary is > pretty rare. There also might well be places where it's valid to have both > fennec and firefox installed (e.g. think of a netbook that can transform into a > tablet), and we don't want them to clash. Yeah, and its already hard enough to simultaneously test/run various versions of firefox together [or even having then use the same application ids]. For example: Install FF 3.5.x with a FF 3.6 and FF 3.7. Since they are all named firefox.exe, the windows process manager thinks they are all the same program, and clicking on one icon from another that is loaded actually runs the loaded program, not the new one being clicked. I would rather see Fennec.exe which the UI is actually different than Firefox.exe anyday. Microsoft certainly doesn't name all Office apps Office.exe. Its even harder for guys to debug code that is running multiple platforms when bugs come up without having ifdefs for each platform path. FWIW, at a high level, it wouldn't hurt if we had something like current branch be FirefoxNext.exe and trunk always be something like MozillaCentral.exe so we can finally run/test them side by side. (which would be another bug)

> Yeah, and its already hard enough to simultaneously test/run various versions > of firefox together [or even having then use the same application ids]. > For example: Install FF 3.5.x with a FF 3.6 and FF 3.7. Since they are all > named firefox.exe, the windows process manager thinks they are all the same > program, and clicking on one icon from another that is loaded actually runs the > loaded program, not the new one being clicked. That is the designed behaviour. You would need to launch firefox.exe on the command line specifying --no-remote and -P to get the different versions running simultaneously, each with their own profile (firefox.exe --no-remote -P)

I really don't think this is the right approach. We're building for the same target, really, it's just a different UI choice at the top level (plus this is a lot of build logic change in multiple trees with NSPR etc).

I'm under the impression that a) WinMo binaries will not install and work properly on WinCE netbooks b) Fennec will eventually be on both WinMo and WinCE c) if they both identify themselves as "wince" in both filename and update platform, there will be confusion and conflicts. Am I wrong in any of these? Does comment #14 still hold if the above are true?

I don't know the answers to all of those, but from the build system perspective it doesn't really matter: if we can have a very small number of touchpoints where we need to make changes, such as the update channel and final release filename, we should do that, rather than make widespread changes across the entire system.

Aki, those three points are correct -- it /may/ be possible to create a single binary that will work on both WinMo and WinCE, but would require work in the code on our end that we're probably not going to do any time soon. So I think where we're at here is that the filenames/product names will be 'firefox' and 'fennec', and now we're just trying to figure out what to do with the platform. The toolchain is actually different; a different SDK is used, etc., even if it's the same compiler.

I proposed on IRC yesterday that we use "arm-wince" for WinCE and "arm-wince-winmo" for Windows Mobile. The platform triplets allow 4-part definitions, with the last two being kernel-os nowadays, as seen in "linux-gnu". This way we could (in configure) check common code in case statements like *-wince*, and specific code with -wince-winmo. We would need to patch config.sub, which we generally take as a pristine copy from upstream, but the maintainer is pretty good about taking patches. Thoughts?

OS_ARCH in makefiles would still be WINCE?

I hadn't actually thought further than that. I got hung up on the configure bits.

(In reply to comment #19) > OS_ARCH in makefiles would still be WINCE? That seems reasonable to me, with OS_TARGET = WINMO. Unfortunately nspr is testing OS_TARGET for WINCE in a bunch of places where as the rest of the code uses OS_ARCH. I think ted is an nspr peer now, so the question to him is if we can switch nspr over to using OS_ARCH like the rest of the tree.

I don't think it's clear at all what the difference between OS_ARCH and OS_TARGET is. I've been using them mostly interchangeably if they exist at all, I think. The canonical difference between them is when you're building a cross-compiler, but that doesn't apply here.

Comment on attachment 410419 [details] [diff] [review] patch Not a thorough review, but for sanity: 1) config.{guess,sub} changes need to get upstreamed. There's a contact address in them, they take patches. I'm not sure how I feel about arm-winmo, I think I'd prefer arm-wince-winmo, as I said, and we could just set the existing WINCE_WINDOWS_MOBILE flag by checking for the presence of that. 2) Please split the NSPR changes into a separate patch. (And if you could provide a patch without 'configure' changes included for review that'd be really helpful.)

Comment on attachment 416128 [details] [diff] [review] patch v.2 >diff --git a/build/autoconf/config.sub b/build/autoconf/config.sub >--- a/build/autoconf/config.sub >+++ b/build/autoconf/config.sub These changes look sane, but can you submit them for inclusion upstream? (the email address is in the file) >diff --git a/configure.in b/configure.in >--- a/configure.in >+++ b/configure.in >@@ -252,7 +252,7 @@ if test "$COMPILE_ENVIRONMENT"; then > > dnl Do some special WinCE toolchain stuff > case "$target" in >-*wince) >+*wince|*winmo) > > MOZ_ARG_WITH_STRING(wince-sdk, > [ --with-wince-sdk=WINCE_SDK_DIR >@@ -265,18 +265,6 @@ case "$target" in > OGLES_SDK_DIR=$withval) > > dnl Default to Windows Mobile components enabled Remove this (now-extraneous) comment. >+ make OGLES_SDK_DIR="$OGLES_SDK_DIR" WINCE_SDK_DIR="$WINCE_SDK_DIR" TOPSRCDIR="$_topsrcdirwin" OBJDIR="$_pwd" target="$target" -C $srcdir/build/wince/tools Can you add some line continuations to this overly-long line while you're here? Looks fine otherwise, r=me with those changes.

Comment on attachment 416129 [details] [diff] [review] nspr patch v.2 >diff --git a/nsprpub/build/autoconf/config.sub b/nsprpub/build/autoconf/config.sub >--- a/nsprpub/build/autoconf/config.sub >+++ b/nsprpub/build/autoconf/config.sub This is just copying the top-level build/autoconf/config.sub to nsprpub, right? (So it's the newer upstream version with your additional changes?) I can land this in NSPR CVS for you when I get a chance, and I can update the snapshot in mozilla-central. I don't know hat would be involved in getting it to 1.9.2, I know NSPR needs an actual versioned release (even if it's beta) for that.

I landed the NSPR patch in CVS: Checking in configure; /cvsroot/mozilla/nsprpub/configure,v <-- configure new revision: 1.263; previous revision: 1.262 done Checking in configure.in; /cvsroot/mozilla/nsprpub/configure.in,v <-- configure.in new revision: 1.267; previous revision: 1.266 done Checking in build/autoconf/config.sub; /cvsroot/mozilla/nsprpub/build/autoconf/config.sub,v <-- config.sub new revision: 1.18; previous revision: 1.17 done Checking in config/rules.mk; /cvsroot/mozilla/nsprpub/config/rules.mk,v <-- rules.mk new revision: 3.76; previous revision: 3.75 done Checking in pr/src/Makefile.in; /cvsroot/mozilla/nsprpub/pr/src/Makefile.in,v <-- Makefile.in new revision: 1.55; previous revision: 1.54 done Checking in pr/src/md/windows/Makefile.in; /cvsroot/mozilla/nsprpub/pr/src/md/windows/Makefile.in,v <-- Makefile.in new revision: 1.20; previous revision: 1.19 done Checking in pr/src/md/windows/objs.mk; /cvsroot/mozilla/nsprpub/pr/src/md/windows/objs.mk,v <-- objs.mk new revision: 1.11; previous revision: 1.10 done

The NSPR update patch for mozilla-central is in bug 507024.

Comment on attachment 416129 [details] [diff] [review] nspr patch v.2 r=wtc.

pushed http://hg.mozilla.org/mozilla-central/rev/c84037a45e9a

'make installer' is broken. Perhaps a "ifeq ($(OS_TARGET),WINCE)"-type test needs updating ?

"WinMo Tracemonkey nightly" is not building since the 11th with: checking target system type... Invalid configuration `arm-wince-winmo': system `winmo' not recognized and then: checking whether the C compiler (: ) works... no *** Fix above errors and then restart with "make -f client.mk build" configure: error: installation or configuration problem: C compiler cannot create executables.

"WinMo Tracemonkey nightly" is not building since the 11th with: checking target system type... Invalid configuration `arm-wince-winmo': system `winmo' not recognized and then: checking whether the C compiler (: ) works... no *** Fix above errors and then restart with "make -f client.mk build" configure: error: installation or configuration problem: C compiler cannot create executables. Is it related to this bug?

Sorry for the double commenting (mid-air collision)

Has Tracemonkey merged from m-c since then? They might just be missing the fixes here.

E10s has the same problem, and we've definitely merged m-c: I think the mozconfig changes for m-c didn't land on the project branches.

For E10s: I've set a clobber to fix machines with existing builds that are failing to cope with the --target=arm-wince-winmo change. There's an error later in the compile for you to fix: e:/builds/moz2_slave/winmo-electrolysis/electrolysis/xpcom/base/nsTraceRefcntImpl.cpp(334) : error C3861: '_getpid': identifier not found For TraceMonkey: need to merge from m-c and clobber.

(In reply to comment #33) > "WinMo Tracemonkey nightly" is not building since the 11th with: > checking target system type... Invalid configuration `arm-wince-winmo': system > `winmo' not recognized > and then: > checking whether the C compiler (: ) works... no I filed Bug 535031 on this issue.

Vlad + Dolske, quite a few people have run into problems/confusion since this landed. I was thinking we should change the wince6 to arm-wince-wince6 and error out or at least warn in configure if arm-wince is specified. What do you guys think?

I don't feel strongly either way.

(In reply to comment #40) > Vlad + Dolske, quite a few people have run into problems/confusion since this > landed. I was thinking we should change the wince6 to arm-wince-wince6 and > error out or at least warn in configure if arm-wince is specified. What do you > guys think? (In reply to comment #41) > I don't feel strongly either way. Is there anything left to do here?

This bug is fixed, I was suggesting extra work to help developers that should be done in a different bug.

Are the changes going to land on 1.9.2 ?

still waiting for approval from drivers

Comment on attachment 416128 [details] [diff] [review] patch v.2 Moving approval request to the list that's getting triaged.

http://hg.mozilla.org/mozilla-central/rev/cac067156b24 WinMo bustage: Electrolysis doesn't have WinMo tinderboxes and we had a silent code race with bug 515748

(In reply to comment #46) > (From update of attachment 416128 [details] [diff] [review]) > Moving approval request to the list that's getting triaged. nominating for 1.9.2, because it blocks bug#533963.

OK, but bug 533963 doesn't block 1.9.2 yet - should it?

Comment on attachment 416128 [details] [diff] [review] patch v.2 Clearing approval nomination until we can get an answer to the above question!