[LLVMdev] Compiling TableGen with Visual Studio

[Chris Lattner]

On Wed, 13 Oct 2004, Morten Ofstad wrote:
> I finally succeded in compiling TableGen with Visual Studio. In the end
> I made normal solution and project files for VS instead of using Paolo's
> SConstruct based build system because of my lacking familiarity with
> SConstruct. One of the main obstacles was getting the FileLexer and
> FileParser to build correctly.

Ok.

> First of all the output file for FileLexer is specified with a %option,
> which is not very convenient because this means I cannot control which
> directory this file is put in. I had to get rid of this line and specify
> the output on the command line instead. I imagine this requires some
> changes to the unix build system, which I'm not really qualified to make.

I don't really have strong feelings about this, but I also don't have time
to play with it right now.  Perhaps others can help you out.

> Second, there are two problems with prototypes. I have a feeling this
> has something to do with generating C or CPP files, as I am generating
> CPP files (correctly, since the .l and .y files contain cpp code and
> should really be named .lpp and .ypp) and the tools behave slightly
> different in this setting. The problems are
>
> in FileLexer.l:
>
> extern "C"
> int yywrap()
>
> which should be (according to VS):
> extern "C" int yywrap ( void )

This is fine and makes sense.  I've applied this patch to fix it:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019260.html


> and in FileParser.y:
> > int yyerror(const char *ErrorMsg)
> > which should be (again according to VS):
> void yyerror(char *ErrorMsg)
>
> in the second case I have to remove the 'const' qualifier because bison
> adds the line 'extern void yyerror(char* s);' to the generated file.

This one isn't good.  In particular, making this change causes warnings to
due to passing constant strings to a function that takes char*.  Is there
any way you can update your bison to a more recent version?  I'm using
1.35 and it seems to work fine.

If that's not possible you can just hack your bison.simple file to include
the right prototype, or set up some way of postprocessing the output of
bison after it's generated (perl script?).

> I would appreciate some input on how we can fix these issues so it's
> possible to build from the same sources on both Unix and Windows in the
> future...

Definitely!

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/