Client compile status

[a'moaca']

Bink: your suggested replacement libavcodec should work with some effort. According to cjkelly1, the library does not compile easily on MSVC 2003 because the developers refuse to support their code working in non-C99 compilers. This also includes... C++. They claim it is a "different language" and the include files should not be expected to work.

EAX: according to cjkelly1, EAX 4.0 (used by Cyan) is not available for free. We are apparently meant to switch to EFX, which comes with OpenAL.

IJL: no longer available. IPP is also expensive like Bink. I changed the client to use IJG jpeglib instead. I don't think anyone will mind. The license is in the README file.

Quicktime is not used.

Edit: Adding jpeglib does have the interesting problem of needing to credit them in documentation, but the documentation is in the Python source.

[Mac_Fife]

Thanks for those comments. I'll work those in as I find time.

The IJG jpeglib license reads a bit like the SSLeay License - "you're free to use this, with or without supplying the source, but you must acknowledge our contribution in anything you distribute".

[JWPlatt]

Edit: Adding jpeglib does have the interesting problem of needing to credit them in documentation, but the documentation is in the Python source.

Doxygen can take care of that.

[cjkelly1]

I have pushed changes to CWE-work, and put build instructions on the wiki at http://squee.openuru.org/index.php?titl ... _MSVC_2003.

As noted in the wiki document, I only modified the "Win32|Release" target (as this will give an External.Release Live build). Any other targets will need to be fixed up.

On a side note, I will file a bug in JIRA for PhysX. Cyan used 2.6.0, but only 2.6.4 is available from nVidia. Changes from 2.6.0 to 2.6.4 have broken regions. I suspect this kind of thing is why Cyan did not update PhysX regularly. Rather a lousy thing to have to fix something that previously worked because some API changed internally.

[Mac_Fife]

Great set of notes!
I'd maybe add an intro paragraph at the top to give this a bit of "context": Explain that this is for CWE and that it specifically applies to CWE-work (just so someone hitting the page from e.g. a Google search can easily see what it's about).

[a'moaca']

I did not realize a totally separate CWE-work was in the long-term plan.

I was okay using this tree and checking in, in the spirit of JW's get 'er done commentary, but I had always expected it would be put in the real repository at some point. In fact I was going to mention that I believe we should set the proper precedent and get these changes code reviewed before they are put into CWE proper. Well, aside from the MS project stuff, I don't know how you'd review that goo. Any volunteers? Please?

OTOH if this work was all checked into a dead end.... never mind. I don't know if you'll see me back soon if so. I thought I was actually contributing to the real deal.

- a'moaca'

[Mac_Fife]

I think CWE-work was just a temporary holding place for you guys to work in while leaving the "original" material in place, while we all experimented with different things, and I wasn't expecting it to survive beyond release day. It probably just needs JW to say when to commit the "CWE-work" back into the main repo. I simply want to clarify that the build instruction won't work on the baseline Cyan code, before someone complains about it.

In the short term, I'm anticipating that we still want (need) to allow people the option of pulling the "unadulterated" version as delivered by Cyan. That might mean setting the "default" of the repo to be different from the "tip", or giving a specific instruction for those who want to do that. It might be that JW would prefer to wipe the current CWE repo and start again, this time making sure that the "empty" folders go up in the initial commit and then have you commit your updates.

Code review would be good, and the right thing to do, but I guess we can only viably review whether the amendments look sensible in the time available?

[Edit] I'd offer to help on reviews, if I could figure out how to do it It doesn't seem to be possible to open a review on CWE-work (it's not on the drop down list) and working through Fisheye seems very slow right now, so blind experimentation isn't too appealing. But, I'm guessing that the workflow needs to commit the updated code back into the "proper" repo before a review can be initiated?

Using IE7 I'm also seeing a little glitch: In Fisheye, when I click on the Create Review button the project selection drop-down appears. Since there's no CWE-work on the list I cancelled it, but the drop-down content remains hovering in front of the Fisheye page.

[rarified]

OTOH if this work was all checked into a dead end.... never mind. I don't know if you'll see me back soon if so. I thought I was actually contributing to the real deal.

Of course the work isn't a dead end. I'm winging a lot of this right now, and don't know what the real flow will be. CWE-work is a child of CWE, and I expect that once we agree on the gating conditions to get changes up to the "golden source", your work will make it there.

Right now I envision contributors pushing changes to CWE-work. After review and any other required states, CWE-work changesets will get pushed to CWE.

_R

[rarified]

I'd offer to help on reviews, if I could figure out how to do it It doesn't seem to be possible to open a review on CWE-work (it's not on the drop down list) and working through Fisheye seems very slow right now, so blind experimentation isn't too appealing. But, I'm guessing that the workflow needs to commit the updated code back into the "proper" repo before a review can be initiated?

We'll have to clarify this one. The 'Review' selector works by project, not by repository. So you should be able to select the 'CWE' project, and then review files from CWE-work (both the CWE and CWE-work repositories are part of the CWE project).

_R

[JWPlatt]

Wonderful work, cjkelly1, both in producing a buildable client and I know that the documentation was an effort in itself. Code can sometimes be so much easier than the docs. This is a tremendous head start from where I thought things would be.

Yep, CWE-work will be merged into CWE before release Tuesday. The result will be the baseline. No dead ends. I'll get with rarified on how to handle process but I intend for CWE-work to go away. We can't be shy about moving forward. Also, I won't be restarting the repo. I enjoy the idea of retaining all the gritty history of a project for folks to see. I also want to make sure those who earn the merit and make the effort get the credit and recognition they deserve - the only "currency" available in open source projects like this.

I will review the code (the diffs), but I won't pretend to have any order of magnitude of competence on Cyan code approaching that of a'moaca' and cjkelly1. Though I should be able to recognize whether there are any Russian Water Tentacles in there.

For the long term, we'll need a development lead to, in part, continue the review process. It is hoped that eager and qualified volunteers will be forthcoming. Any of you on the team right now is welcome to the position of your choice.

There is no "unadulterated" version as delivered by Cyan in the repo. Folks who want to see or play with what was delivered by Cyan will need the raw MOULOpenSourceClientPlugin.zip download found on the wiki. Mercurial tracks files, not folders, so my initial commit and push from the raw sources omitted the empty SDK folders. When I realized this, I committed placeholder.txt files into each empty folder and pushed that. So while you could say it was purely Cyan code, the repo was different from the outset and it will retain that history.