Move from using make-jars.pl to JarMaker.py and preprocessor.pl to Preprocessor.py

[ilikenwf]

Currently we're using an ancient script to make our jars, it's just that I'd rather get things building before we fix this. Tagging @Mook and @GeekShadow for commentary and so they can maybe remind me sometime.

[johnmurrayvi]

I have the JarMaker.py and Preprocessor.py scripts working in my xul-9.0.1 branch with python2: https://github.com/johnmurrayvi/nightingale-hacking/commit/b2595032afc7d82f0cfc2fca72e5ddcfe8e03ca2

I had to copy some extra python scripts in the deps for them to function correctly: https://github.com/johnmurrayvi/nightingale-deps/commit/5313e544d400a78d6b8d5a9497746de6939f0a5f

[ilikenwf]

Nice...feel free to cherry pick it where appropriate :)

[johnmurrayvi]

I have sb-trunk-oldxul building with the new scripts (I just copied them into the mozilla-1.9.2//scripts dirs), and now I'm trying to build the xul-192-new branch of the deps and am running into this error:

mozilla/js/src/nanojit/NativeX64.cpp: In member function ‘void nanojit::Assembler::underrunProtect(ptrdifft)’: mozilla/js/src/nanojit/NativeX64.cpp:1405:52: error: no matching function for call to ‘nanojit::Assembler::codeAlloc(nanojit::NIns&, nanojit::NIns_&, nanojit::NIns*&)’ (... couple others, but all nanjit::Assembler::codeAlloc)

Have you run into this before? I haven't tried building the 192 deps in a long time and don't recall that error.

[ilikenwf]

Same here. I think it may have been a build option or something. We could almost just extract the deps and recompress with the new scripts.

Of course its really just the make xulrunner SDK bash script on deps that matters...I think...and removing the oldmozscripts dir. On Jun 13, 2013 3:47 PM, "John Murray" notifications@github.com wrote:

I have sb-trunk-oldxul building with the new scripts (I just copied them into the mozilla-1.9.2//scripts dirs), and now I'm trying to build the xul-192-new branch of the deps and am running into this error:

mozilla/js/src/nanojit/NativeX64.cpp: In member function ‘void nanojit::Assembler::underrunProtect(ptrdifft)’: mozilla/js/src/nanojit/NativeX64.cpp:1405:52: error: no matching function for call to ‘nanojit::Assembler::codeAlloc(nanojit::NIns&, nanojit::NIns_&, nanojit::NIns*&)’ (... couple others, but all nanjit::Assembler::codeAlloc)

Have you run into this before? I haven't tried building the 192 deps in a long time and don't recall that error.

— Reply to this email directly or view it on GitHubhttps://github.com/nightingale-media-player/nightingale-hacking/issues/126#issuecomment-19423907 .

[ilikenwf]

Last build I did for the release, and ended up messing with the config files for a couple days to get it right. Thought I committed those though.

[johnmurrayvi]

That's probably a better (and much quicker) way than rebuilding. I think I found a hacky fix from the mozilla history: https://github.com/mozilla/mozilla-central/commit/b3c640ba28c35455f1769a0b44e49bf6ffcc5a60

Tried building with it, but got another error. Seems like 1.9.3 fixes it: https://code.google.com/p/packaging-spidermonkey/issues/detail?id=1

Hmm, I'll look at those commits tonight some more, it looks like a fair amount was changed in the configs as well as the cxxflags

[ilikenwf]

Ha...at this rate going with xul9 and step stoning up to whatever's current is probably the best fix...

On Thu, Jun 13, 2013 at 4:19 PM, John Murray notifications@github.comwrote:

That's probably a better (and much quicker) way than rebuilding. I think I found a hacky fix from the mozilla history: mozilla/mozilla-central@b3c640bhttps://github.com/mozilla/mozilla-central/commit/b3c640ba28c35455f1769a0b44e49bf6ffcc5a60

Tried building with it, but got another error. Seems like 1.9.3 fixes it: https://code.google.com/p/packaging-spidermonkey/issues/detail?id=1

— Reply to this email directly or view it on GitHubhttps://github.com/nightingale-media-player/nightingale-hacking/issues/126#issuecomment-19425825 .

[johnmurrayvi]

Very true... I've hit a road block on it for the time being I think. Everything compiles but it's failing to load some of the mozilla modules when I try to run it, stopping the songbird/nightingale core components from being able to register. It seems like it could be from the vendor/mozbrowser deps.

On Thu, Jun 13, 2013 at 4:23 PM, Matt Parnell notifications@github.comwrote:

Ha...at this rate going with xul9 and step stoning up to whatever's current is probably the best fix...

On Thu, Jun 13, 2013 at 4:19 PM, John Murray notifications@github.comwrote:

That's probably a better (and much quicker) way than rebuilding. I think I found a hacky fix from the mozilla history: mozilla/mozilla-central@b3c640b< https://github.com/mozilla/mozilla-central/commit/b3c640ba28c35455f1769a0b44e49bf6ffcc5a60>

Tried building with it, but got another error. Seems like 1.9.3 fixes it: https://code.google.com/p/packaging-spidermonkey/issues/detail?id=1

— Reply to this email directly or view it on GitHub< https://github.com/nightingale-media-player/nightingale-hacking/issues/126#issuecomment-19425825>

.

— Reply to this email directly or view it on GitHubhttps://github.com/nightingale-media-player/nightingale-hacking/issues/126#issuecomment-19425992 .

[ilikenwf]

That's going to be fun. I believe those "vendor" deps are just some sort of strange SDK that POTI stuck together with bits of mozilla...

[freaktechnik]

I want to mention #164 in this context. The old deps didn't build all components.

[johnmurrayvi]

I just want to mention how much of an idiot I am, and I have no better place to do it, plus I figured it might give someone a laugh.

I've been thinking I've been building the xul 9.0.1 deps I have been building for like the past few weeks now. Turns out, I deleted the wrong "mozilla-release" directory after using xul 6 to try some things (I have 5-6 versions of xulrunner in that dir), and that's what I have been building against, and thought I had been patching them for gcc 4.7/making tweaks, and in general, trying to figure out why things weren't working while looking at bugs fixed before xul 9.

I almost just tried to hide all of this out of embarrassment, but the evidence of it is already in the deps repo. The good news is all of the updates and changes I've been working on, mainly the components/modules, is still applicable, but I essentially wasted days trying to get things up and running, without realizing why it wasn't actually working.

Sigh....

Already got the real 9.0.1 deps built now, so hopefully things progress.

Edit: For the record, I did have the 9.0.1 deps initially, then I distinctly remember, a few days/weeks ago, undoing changes I had made before.

[ilikenwf]

@johnmurrayvi So if this is done, you get the honor of clicking the close button :+1: