BASIC, IMCC, and Windows.
Clinton A. Pierce
stuff through IMCC for performance reasons and whatnot.
The suggestion was also made (by me!) that I could produce a "milestone"
binary for Windows for distribution.
Well, my first attempt at all of the above didn't go well. I can't quite
fathom how I'm supposed to build IMCC in a Win32 environment without
mixing/matching cygwin and MSVC. Parrot builds fine and by-the-book (perl
Configure.pl, nmake, nmake test, etc...) and runs against the Activestate
Perl distribution just peachy.
IMCC seems to want headers that MSVC++ isn't happy with:
cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE
-DNO_STRICT -I../../include -Feim
cparser.obj -c imcparser.c
imcparser.c
C:\Program Files\Microsoft Visual Studio
.NET\Vc7\PlatformSDK\Include\WinDef.h(159) : error
C2059: syntax error : 'constant'
C:\Program Files\Microsoft Visual Studio
.NET\Vc7\PlatformSDK\Include\WinNT.h(257) : error C
2059: syntax error : 'constant'
C:\Program Files\Microsoft Visual Studio
.NET\Vc7\PlatformSDK\Include\WinNT.h(262) : error C
2059: syntax error : 'constant'
[...hundreds of errors later...]
And it also seems to want (by reading the makefile) bison and flex, neither
of which is available in the MSVC Win32 compilation environment. Should I
mix and match at least those two components (flex/bison)? Has anyone built
IMCC for Win32 before?
Dan Sugalski
>The suggestion was made last week that I try filtering the compiled
>BASIC stuff through IMCC for performance reasons and whatnot.
>
>The suggestion was also made (by me!) that I could produce a
>"milestone" binary for Windows for distribution.
>
>Well, my first attempt at all of the above didn't go well. I can't
>quite fathom how I'm supposed to build IMCC in a Win32 environment
>without mixing/matching cygwin and MSVC. Parrot builds fine and
>by-the-book (perl Configure.pl, nmake, nmake test, etc...) and runs
>against the Activestate Perl distribution just peachy.
>
>IMCC seems to want headers that MSVC++ isn't happy with:
Which we need to fix. I think for 0.0.11/0.1.0 I want to dump the
IMCC/parrot difference and just have one single binary.
>And it also seems to want (by reading the makefile) bison and flex,
>neither of which is available in the MSVC Win32 compilation
>environment.
This is a problem with timestamps, so far as I can tell. Neither
bison nor flex are actually needed, as the generated files are
checked into CVS. Make just thinks they need to be regenerated.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> The suggestion was made last week that I try filtering the compiled
> BASIC stuff through IMCC for performance reasons and whatnot.
> IMCC seems to want headers that MSVC++ isn't happy with:
>
> cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
> -I../../include -Feim
> cparser.obj -c imcparser.c
> imcparser.c
> C:\Program Files\Microsoft Visual Studio
> .NET\Vc7\PlatformSDK\Include\WinDef.h(159) : error
> C2059: syntax error : 'constant'
Can you have a look at the stated line, maybe its some kind of a name
clash. Would also be nice for giure out, by which file WinDef.h got
pulled in.
> And it also seems to want (by reading the makefile) bison and flex,
No, the generated files are in CVS. If there is a timestamp problem,
just touch imcparser.* and imclexer.c. And of course there are
flex/bisons for Win out there somewhere, if one wants actually change
the .l/.y sources.
leo
Nicholas Clark
> Clinton A. Pierce wrote:
> >And it also seems to want (by reading the makefile) bison and flex,
>
> No, the generated files are in CVS. If there is a timestamp problem,
> just touch imcparser.* and imclexer.c. And of course there are
> flex/bisons for Win out there somewhere, if one wants actually change
> the .l/.y sources.
Could we bodge round this by adding a Configure.pl flag to suppress adding
the rules to use bison (or add in more rules to defeat any make default rules,
as I think perl5 does), and default this to suppress?
The 3 or 4 people on this list who do want to edit those files are on-the-ball
enough to remember to run Configure.pl in such a way to turn off the suppress.
I think that this would make life easier for everyone. (because it also saves
the 3 or 4 people on the list having to read tedious e-mail messages from
people about the subject)
Nicholas Clark
Leopold Toetsch
> On Thu, Mar 20, 2003 at 04:53:22PM +0100, Leopold Toetsch wrote:
> And of course there are
>>flex/bisons for Win out there somewhere, if one wants actually change
>>the .l/.y sources.
> Could we bodge round this by adding a Configure.pl flag to suppress adding
> the rules to use bison (or add in more rules to defeat any make default rules,
> as I think perl5 does), and default this to suppress?
I don't have any indications till now, that this was the problem in the
first place - error messages where not about trying to run bison or some
such, but about wrongly? pulled in includes, which then choked somewhere.
> The 3 or 4 people on this list who do want to edit those files are on-the-ball
> enough to remember to run Configure.pl in such a way to turn off the suppress.
Which is a major PITA during development. The current method is a
compromise of course. But, when the timestamp of generated files is
always after that of sources[1], and there is no over dependency[2] then
on sources, the current procedure should be ok.
[1] is done by my check-in script or by $devoloper
[2] should easily be verified in the Makefile
> I think that this would make life easier for everyone. (because it also saves
> the 3 or 4 people on the list having to read tedious e-mail messages from
> people about the subject)
I'm currently not sure, if there are 4 people around, that compile imcc
on native windows :-) Anyway, the current problem is not that bison/flex
got invoked (which isn't that problem either - every project has some
prerequesits) but is somewhere else. If there is a better solution for
solving the generated files problem (which AFAIK currently is not on the
air) I'll all ok with it.
> Nicholas Clark
leo
Steve Fink
> Nicholas Clark wrote:
>
> >I think that this would make life easier for everyone. (because it also
> >saves
> >the 3 or 4 people on the list having to read tedious e-mail messages from
> >people about the subject)
>
> I'm currently not sure, if there are 4 people around, that compile imcc
> on native windows :-) Anyway, the current problem is not that bison/flex
> got invoked (which isn't that problem either - every project has some
> prerequesits) but is somewhere else. If there is a better solution for
> solving the generated files problem (which AFAIK currently is not on the
> air) I'll all ok with it.
I implemented a fix for this that people seemed to like a few months
back, but never got around to finishing it off and committing it. It
replaces timestamps with checksums for determining the dependencies.
Sorry about that -- I'll try to polish it off and commit it in the
next day or three, when I find the time.
I'll attach the preliminary patch I made back then, just in case
someone else feels motivated to finish it off.
Clinton A. Pierce
>Clinton A. Pierce wrote:
>
>>The suggestion was made last week that I try filtering the compiled BASIC
>>stuff through IMCC for performance reasons and whatnot.
>
>
>>IMCC seems to want headers that MSVC++ isn't happy with:
>> cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
>>-I../../include -Feim
>>cparser.obj -c imcparser.c
>>imcparser.c
>>C:\Program Files\Microsoft Visual Studio
>>.NET\Vc7\PlatformSDK\Include\WinDef.h(159) : error
>>C2059: syntax error : 'constant'
>
>
>Can you have a look at the stated line, maybe its some kind of a name
>clash. Would also be nice for giure out, by which file WinDef.h got pulled in.
It's because in imcparser.c the token CONST is used. In the standard
Windows stuff, const is defined as
#define CONST const
Which of course is a keyword and used everywhere in Win32 header files like:
typedef CONST WTHINGY *FOO, *BAR...
Changing this to CONSTX in imcparser.c (or any other token) seems to be
okay. I don't have the necessary tools to fix this directly (bison, etc..).
Also in imc.c ~431:
done:
}
Makes MSVC unhappy. Changing this to:
done:
1;
}
Makes everything all right so far, but I still don't quite have a working
imcc. Still slugging through all of this.