Building Torque with Project Builder 2.1

#21 Ah, yeah, the 2nd build to convince ProjectBuilder to copy the app. I've been able to get around that 2nd build thing, by changing the projects build product directory.

In the list of files, at the very top, is a reference to the project itself. click it.
Get info.
Set place build products for this project in a seperate location.
Set that locaiton to ../example .

that gets the December tools, & I think the July tools to actually copy the app to the right place.

#22 Okay, so I should run the target inside of example. I built the project twice in a row without doing anything else (I assumed you meant "build" instead of "make"). I looked inside of the example folder and I found nothing new. When I try running (command-R), I get the message "Error: Failed to open Main.cs". There is a main.cs in the example directory.

You say to manually update the working directory listed inside PB for the executable to point to the one in the Example directory. Even if I could see an executable in the example directory, what would it look like and exactly how do I go about doing what you are telling me to do (i.e., manually update the working directory listed inside PB for the executable to point to the one in the Example directory)? Also, I never found the executables tab that you mentioned in the readme file.

#23 I can confirm Roger's problem : double clicking on the app in the example directory after a clean build, lead to the main.cs missing thingy...
I just updated to December tools, did a clean check out on my local repository, built it (and ran into the build error that is a showstopper atm, unless you toggle off the stop building on errors in the PB prefs (or something close to that). That gets rid of that first failture, and goes on building. Toggle it back afterwards, so you spot errors more easily ;)). It copied it to the right folder, but when started, it does exactly as Roger described.
I didn't look into it that much last night, as it was getting late, and my eyes were being funny with me, again :)

David C. : as anything changed in your last commits, ie has MB's way of packing things in the bundle been checked into HEAD ? (I don't think so, but wondering). Or in the way of looking at what is the cwd ?

Anyhow, I'll try to find the problem this afternoon, no promises :)
Btw, nice to see quite a few new faces getting involved with the Mac side of things : welcome :)

Edit : Okay, I tried moving the whole scripts hierarchy + the top main.cs inside the bundle, like MB does, just to see if that would work, and it doesn't : still no go, the exe starts, complains about the missing main.cs and exits (both by having them at the root of the bundle, and inside the contents folder). No info from torque's console.log, as it doesn't get generated because of the early exit, and no crash report, since it ain't crashing..
Weird...

#24 Hello (again) David,

I can confirm that Paul's solution solves the 'double compile' problem by making the Copy File Phase obsolete.

I also stepped with the debugger through the 'not so bad' Carbon code (no offense intended ;-) and probably found the place which causes the problem: the FSGetCatalogInfo call returns an error code -35 in the macGetHomeDirectory function.

Hope that helps fixing the problem.

BTW, if your new routines aren't Carbon based, I would like to help making them stable :-)

yours kodi

#25 Damn! Mac people coming out of the woodwork! Took long enough...

Okay. Here we go:

- I will integrate Paul's changes into the new 2.1 project file, hopefully checked in in the next few days.

- The only time I had problems with main.cs was running within PB, where the working directory was wrong. Otherwise, the code has been working fine.

HOWEVER, there's a caveat -- I believe if your path has certain 'bad' characters in it, it can cause things to fail.

- The new code I've been working on is all Carbon and Unicode. Don't know when it might get checked in. I haven't been rushing bc it doesn't work potentially on some older OSes (certainly nothing pre-9.0, and possibly some early 9s don't have a new enough Carbon -- but I have to check whether that's really the case). Also bc if it isn't replacing every piece of the current file io, it's not 'done'. ;)

- Putting stuff inside the Package I can certainly add. However, in terms of developing, it makes for a pain in the ass to have the content deep into a package... ;) Might be good for shipping.. however, you run into the issue that a CFM app, while able to be Packaged, likes being just like PC/etc. apps at the top level. And I'm still heavily pushing Carbon CFM as the 'normal' way to ship apps for the near future.

Some good catches. I'll look into the io stuff and figure out why it was working just fine for all the Orbz builds we've done in the past few weeks, but you guys (including Nic) seem to be having problems locating main.cs. Note again that if you don't have the debug executable pointing to the right exe, with the right working directory, the debugger is giving you 'false positives' on any errors.

d

#26 @Paul:

Cool... that worked perfectly. I should have realized I could do that. Of course, I hate having other junk cluttering up /example, but an extra folder or two won't hurt.

@Everyone:

My screwup -- the problem with working with a bunch of different project simultaneously is that I sometimes lose which one has the 'latest' code, or mis-merge things.

The main.cs problem is a bug in some minor refinements I was back-porting to the current code in order to solve an issue or two I had seen happen. I should have an update macCarbFileio checked in, along with a project, in the next hour.

d

#27 New fileio.cc and PB 2.1 project files are checked in.

fileio has a faster, more reliable system for getting base path of app/package, as well as detecting being packaged. there was a minor bug which I didn't pick up on bc I've been doing CW/CFM builds and not PB builds for the last ten days or so -- that was the "couldn't find main.cs" issue.

new PB project builds target exe directly into /example, so no extra build step needed, no extra debug executable entry needed, everything (crossing fingers) should just work. Damn me that it took a year and a half to resolve that!

let me know if people run into any problems with this.

d

#28 David

Thanks for the quick fix, I thought i was loosing my mind...but I guess it was yours...J/K :-)

Anyway,, I got it to build and run from PB.. just fine... but I still had to change the build paths
for the Project, just to let you know they didnt come through as being changed to the example folder
from th HEAD file... But no biggie.. everything seems to be working great now on this end

Jeff

#29 Jeff -

Interesting. Might be that the project build stuff is tied to the user settings, and while I had been checking in my setting (as 'root', yes, I'm a bad, bad unix user... ;), I stopped doing that.

After a few more people try it out, I'll update the readme with new instructions... not that anyone READS it anyway. ;)

d

#30 I updated to your new version and did a build on the project torque_pb_2_1.pbproj. The build succeeded (with 65 warnings). When I tried to run the project, it said, "Run session cancelled: No launchable executable present to run."

Also, what is HEAD? I'm still in the dark on that?

Thanks.

#31 Weird -- not sure why you'd get this. but note that I'm rushing out these fixes quickly, and don't have time to check permutations (let alone build the freaking thing...). PB is SOOOOOOOO slow versus CW on my system that I am now ONLY supporting it as a community aid -- I'm not doing any coding in PB from this point on.

As for "HEAD", that means "get the code without specifying a label". If you grab a labelled release (like 1_1_2), you get the snapshot at that point. The 'head' is the latest checked in code.

d

#32 @David: thanks, glad it helped. I'm a little confused about the cluttering the /example folder though... my setup just gives me the app there.

Perhaps you have placed the intermediate build products there as well? the intermediate build products can be left in the normal place, a folder beside the project file named 'build'. On that same info pane, the second option is for the intermediate products.
And now that I look at it: ya, you do have to explicity put those intermediates somewhere else. So:

In the list of files, at the very top, is a reference to the project itself. click it.
Get info.
Set place intermediate build files for this project in a seperate location.
Set that locaiton to build .

that should solve the clutter prob, I think.

#33 Yeah, I did that, but for some reason I got a folder in /example. might be that something else 'legacy' in the project file is bound to the target-build-dir, and thus relocating the target has that reloc as well.

Otherwise seems fine to me.

Just checked in another pass of changes to the fileio stuff. Not much of an issue for all you PB folks, but I totally and completely blew the code for Carbon/CFM builds when I went to fix the PB builds. Oooops. Hopefully the new stuff works properly on both. ;)

d

#34 David,

With the problem I'm having getting off the ground, would you recommend going with Metrowerks? I think they are having a sale if you buy in the next couple of weeks or so. I stopped using them because of the cost, but maybe they are worth a try. Anyway, would these building problems I'm having go away with Code Warrior? Also, is there a simple "Hello, World!" type project for Torque for the Macintosh somewhere? Thanks.

#35 Roger -

I have full metrowerks, and yes, it's much simpler to deal with. However, different people have different opinions. Supposedly there's some $99 version that just builds for OSX. Trying to pull new users in, and then get them hooked for the next version. ;) I wouldn't buy that, since I want to be able to build OS9/OSX/Win apps, but if you're only planning on targeting OSX, it sounds like a potentially good deal. It is MUCH MUCH faster than PB in build times (at least, with no precompiled headers, which I don't like to deal with when I'm constantly changing core headers... ;) ).

On the other hand, you simply shouldn't be having any problems. :) Other people seem to be getting along just fine.

With the new project, you DO need to read the new README in the PB folder and follow those new instructions, to make sure the executable goes in the right place. But then it should work.

And note that the main.cs problem wasn't your problem, or necessarily a PB problem, but an issue in the new fileio code I've been tweaking along the way...

d

#36 Just two cents here, I was so fed up with PB 2.1 (see above) that I bought the Metrowerks OS X Suite ($109 with FedEx Shipping) - all I can say is that I heartily recommend this idea to anyone annoyed with Project Builder (and it arrived in less than 40 hours)...

Now maybe this is for a new thread - but I'm still having build problems - now mainly related to linking and classic libraries that obviously didn't come with my x-only deal. Admittedly, I cracked open the package only an hour or so ago - so maybe I'll quit whining and start up a fresh thread when I have some details...

#37 PB 2.1 builds now without issues, so far as I know.

CW8 for X will only be able to build the X targets in the project. And since I haven't built/tested them since I first created those targets under CW7, your mileage may vary. ;)

d

#38 I am using PB2.1, I have followed the readme instructions
("show info-> ../example"). The build is always
successful (with 65 warnings) but whenever I try to run
the executable, it just stays there idle. Not even a
window would pop up. Could someone please possibly
direct me to the right direction? Actually, my ibook only
has Radeon 7500 (16Mb) for graphics card. Would that be an
issue?

Thanks a lot

#39 is there a console.log output file?

have you tried running under the PB debugger, to see what it is doing?

I've been mostly off coding on Orbz, so I wouldn't necessarily know if something new has cropped up.

d

#40 Yes, there is a console.log file.

//-------------------------- 2/1/2003 -- 21:25:25 -----
System & Processor Information:
MacOS version: 10.2.3
CarbonLib version: 1.6.0
Physical RAM: 384MB
Logical RAM: 2047MB
PowerPC G3, 700 Mhz
FPU detected

Math Init:
Installing Standard C extensions

Input Init:
Basic mouse capture failed to enable!

Video Init:
Accelerated OpenGL display device detected.

setModPaths: invalid mod path directory name: 'fps'
setModPaths: invalid mod path directory name: 'common'
--------- Loading MODS ---------
Missing file: common/main.cs!
Missing file: fps/main.cs!

--------- Parsing Arguments ---------
Engine initialized...