[sldev] Build errors(in XCode 2.5) with indra.y.h

Michael Miller 1337mail at gmail.com
Mon Oct 1 13:03:13 PDT 2007


I made a JIRA issue at http://jira.secondlife.com/browse/VWR-2620.

I vote for an n-way ifdef statement. Adding more build steps adds (in
my opinion) a considerable amount more bloat to the development
environment and makes things messy.

Moreover, I think it's proper to generate .hpp files for .cpp files. I
consider this to be a bug in the older versions.

Can someone write the n-way ifdef statement and post it here? Nothing
I've tried so far works.

Thanks,
Mike

PS: Does XCode 3.0 work for you? For me it gives a bunch of internal
errors about inserting nil into an array. I filed a bug report with
Apple, but I'm just wondering if you had a similar issue.

On 10/1/07, Ben Byer <bbyer at mm.st> wrote:
>
> On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote:
> >> Isn't there an option somewhere in XCode to force YACC to
> >> output .h?
> >
> > Did you try the change I suggested for the SConstruct?
>
> Unfortunately, that's not going to help -- XCode uses its own build
> system, bypassing SConstruct.
>
> On Oct 1, 2007, at 3:09 AM, Soft wrote:
>
> > In looking for the difference here: Does 2.5 perhaps come with an
> > updated lex and yacc? With 2.4.1 and 10.4, I've got flex 2.5.4
> > (ancient!) and Berkeley yacc 1.9 (ancient too). I've been hoping for
> > an update on the former and a switch to bison for the latter.
>
> I'm not sure about 2.5, but 3.0 has:
>
> bbyer:lscript_compile bbyer$ lex --version
> flex 2.5.33
> bbyer:lscript_compile bbyer$ yacc --version
> bison (GNU Bison) 2.3
>
> Xcode seems to be automatically executing the following line when it
> encounters a .y file:
>
> bbyer:lscript_compile bbyer$ yacc -o indra.y.cpp -d indra.y
> conflicts: 88 reduce/reduce
> bbyer:lscript_compile bbyer$ ls -l indra.y*
> -rw-r--r--  1 bbyer  wheel   45812 Sep 20 12:33 indra.y
> -rw-r--r--  1 bbyer  wheel  146221 Oct  1 12:31 indra.y.cpp
> -rw-r--r--  1 bbyer  wheel    6131 Oct  1 12:31 indra.y.hpp
>
> This is, presumably, because:
>
>         -d
>                Write an extra output file containing macro definitions
> for the token type names defined in
>                 the grammar and the semantic value typeYYSTYPE, as well as a few
> extern variable declarations.
>
>                If the parser output file is named name.c then this
> file is named name.h.
>
>
>       -o outfile
>         --output-file=outfile
>                Specify the name outfile for the parser file.
>
>                The other output files' names are constructed from
> outfile as described under the -v and -d switches.
>
>
> ... so I guess that that's how -d responds when you tell it you want
> a .cpp file.
>
> Do we want to fix this in the source code (by adding a third term to
> the #ifdef), or as a custom build step in the .xcodeproj?
>
> -b
>
> PS Also watch out for http://jira.secondlife.com/browse/VWR-2551 when
> building with late versions of XCode.
>


More information about the SLDev mailing list