On Thu, Jun 12, 2008 at 11:58 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
> On 6/13/08, Ari Johnson <[EMAIL PROTECTED]> wrote:
>> On Thu, Jun 12, 2008 at 10:55 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
>>  > Ari, when you get the time, is it possible to write down someplace
>>  > what all is involved in building the mac builds the way you want it to
>>  > be done?
>>  > In the forums, ( http://forums.wz2100.net/viewtopic.php?f=19&t=1747 ),
>>  > people have issues, but I don't know what the 'correct' fix is, or how
>>  > to explain the process to them.
>>
>>
>> That documentation is cleverly hidden in macosx/README.BUILD.txt where
>>  it has been located since I first created the Mac port. :)
>>
> LOL :o ... guess you can tell I never even bothered to look.
>
>>  >
>>  > That way, it would be easier to know what breaks, (and how NOT to
>>  > break) mac builds.
>>
>>
>> That's one thing I try to keep consistent and which has not been
>>  maintained as faithfully by other developers: A simple build process
>>  that has as its only prerequisites Mac OS X 10.4 or higher, Xcode, and
>>  the Warzone sources.  Given those things, it has (ever since I
>>  converted the port to an Xcode project) been a single command in the
>>  terminal that generates the .app.
>
> I wonder if it could be possible for you (or someone you trust) to
> allow remote logins into your machine, and then see if it still builds
> ok or not?  Or can't you build something that way?
> Or, perhaps you can have a script that autobuilds the source code, and
> if it fails, you send a automated e-mail to the ML, saying that rxxxx
> broke mac builds. (or something like that.)
> That way, we know there is a problem that needs fixing ASAP.
>
>
> You wouldn't happen to know what causes (or caused)  this would you:
> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.h\ \"${INPUT_FILE_PATH}\"\
> ||\ exit\ 1
> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.c\ \"${INPUT_FILE_PATH}\"\
> ||\ exit\ 1
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
> unrecognized: %name_prefix
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
> Skipping to next %
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
> unrecognized: %destructor
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
> Skipping to next %
> ** BUILD FAILED **
>
> Or is that now fixed?
> It seems weird it sees %name_prefix, and not %name-prefix.

That was caused by someone changing our .y files to require a version
of Bison newer than the one included with OS X.  The problem is that I
now have to get the Xcode project to build and use a newer version of
Bison automatically to counter that, because I don't want to rely on
ANYTHING that I didn't list above.  And I don't have time to finish
that process.  Freddie, on the other hand, didn't bother to do that
with Bison and just used DarwinPorts or Fink to install a newer
version of Bison and rely on that (also for time constraint reasons on
his part)

_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev

Reply via email to