[CCC DEV] OSCON Prep: Windows Distribution, SVN Commit Rights, Winsparkle Integration

[Matt Jadud]

On Mon, Jul 5, 2010 at 6:10 PM, Dave Gilmore <gilmorenator at gmail.com> wrote:
> I’ve managed to fix and test all of these on a Windows XP SP3 Virtual
> Machine,

No one in the Real World has updated to Windows 7 yet, so this should
cover about 98% of all normal use-cases. We should probably check SP2
as well... I don't think everyone is up to SP3 yet. ;)

Cool.

> Can I either get permission to commit my changes or pass the changes to
> someone else to commit?

All in favor? All against?

I'll add you to the commit list. Congrats. You're on the team, by
virtue of the fact that you're Doing Stuff. Don't screw too many
things up, or I might have to fly over and visit Scotland. Alas.

> When executing build_occplug.sh there is some deprecated java calls – which
> don’t mess with the build process but probably should be changed – I can do
> this if required,

I'm not familiar with the script, as this is an invention of
Christian's. If it runs faster, and still works, I'd say you should
commit changes. If it only takes a long time, but works, and "fixing
it" would take a huge amount of time... it might not be worthwhile
*right now*. That is, things that work (and are slow) are better than
"things that used to work, but then I tried to make it faster, and now
it doesn't work at all..."

Your call on that one.

> The build_kroc.sh seemed to take a complete lifetime to finish it’s
> execution – I actually fell asleep at one point! (Lazy Student....),

Yep. It not only built the toolchain (fast), it pre-compiled all the
libraries (slow-ish). A lot of that time is spent running the occam
compiler on occam source files, not building the tools themselves.

> I noticed a large number of unrecognised calls during the execution of this
> script which might be an attributing factor,

These don't hurt anything, and I don't think they slow it down. We
pass some arguments recursively through the make process that aren't
used everywhere. Someday, we'll clean that up, so that the warnings
will go away.

> I’m not sure what that’s all about – not investigated it fully yet, can
> anyone shed a light on it?

See above.

> If we can sort that out and retest I think we are pretty close to a usable
> distribution based on the existing distribution of course something else
> will crop up!

Invariably. :)

> would be happy to do this – though we’ll need an xml (appcast) file on the
> server which we want to get the updates from and I doubt I’ll have access,

Either:

1. For testing, you can run against a web space you have access to, or
2. I can give you access to a server where you can put the appcast file.

I'm not able to casually give you access to concurrency.cc at this
time. That said, if it works against an appcast URL *anywhere*, we can
easily move it to the server.

> The Innosetup stuff also needs looked at so if someone can tell me where to
> grab that from I can assist Christian or whoever,

Christian is, or was, at a music festival. He arrives over here in the
US around 23:00 GMT-5 on Wednesday. We'll be focusing on all of this
once he is un-jetlagged. So, he might be able to catch you with some
notes before then.

> I guess for now we need to figure out the Unrecognised options problem and
> commit any changes I’ve made to the build script before looking at Innosetup
> or Winsparkle,

Unrecognized is a known thing, but doesn't break anything (just a
noisy build that should be fixed... perhaps I should start using our
Trac instance to create tickets. I'll do that now.) I'll go ahead and
give you commit privs to... well, trunk, I guess. If you break the
build, try and only break the Windows build.

Actually, you have to create an account on "csprojects" first.

http://projects.cs.kent.ac.uk/

There's a button there to create an account. After you do that, send
me an email with your username, and I'll set you up.

Cheers,
Matt