On 20 September 2010 20:28, Seth Hetu <[email protected]> wrote:
> David, I get a weird error building with the latest (SVN) source & the
> latest (SVN) sconscript file:
> -------------------------------------------------------------
> fbc -lang deprecated -c build\loading.bas -o build\game-loading.o -mt
> -g -exx -s gui -d IS_GAME -m game
> build\loading.bas(554) error 56: Illegal specification, at parameter 1
> (zmap) of CleanZoneMap()
> SUB CleanZoneMap(zmap as ZoneMap, BYVAL wide as integer, BYVAL high as 
> integer)
>                         ^
> build\loading.bas(555) error 25: Invalid data types
>  WITH zmap
>       ^
> ....(and more errors)
> -------------------------------------------------------------------
> Any ideas?

Weird. Is udts.bi present in build/ ? Does it compile if you use one
of the other build systems?

> By the way, gcc is now properly invoked through mingw, thanks!
>
> -->Seth
>
>
>
>
> On Mon, Sep 20, 2010 at 3:32 PM, David Gowers (kampu) <[email protected]> 
> wrote:
>> On Sun, Sep 19, 2010 at 9:08 PM, Ralph Versteegen <[email protected]> wrote:
>>> On 19 September 2010 11:37, David Gowers (kampu) <[email protected]> wrote:
>>>> On Sun, Sep 19, 2010 at 8:49 AM, James Paige <[email protected]> 
>>>> wrote:
>>>>> On Sat, Sep 18, 2010 at 04:05:49PM -0700, [email protected] 
>>>>> wrote:
>>>>>> kampu
>>>>>> 2010-09-18 16:05:49 -0700 (Sat, 18 Sep 2010)
>>>>>> 112
>>>>>> SConstruct based build system. Builds game, custom, and bam2mid 
>>>>>> currently.
>>>>>>
>>>>>> Still needs more testing on Windows.
>>>>>> ---
>>>>>> A   wip/SConscript
>>>>>> A   wip/SConstruct
>>>>>> A   wip/ohrbuild.py
>>>>>
>>>>> Fails for me on compiling audwrap
>>>>>
>>>>> I don't know if audwrap has ever been compileable on my machine, as I
>>>>> test with music_sdl almost 100% of the time.
>>>>>
>>>> Good point. It is a little overzealous. I've attached a fixed version
>>>> which only adds it as a default target when it's actually going to be
>>>> used. If it works for you, I'll commit.
>>>
>>> I see you forgot music_silence in the list of supported backends.
>>>
>>> When I try to compile, gcc crashes. gcc of course runs just fine if I
>>> run it with the same options from the commandline. I added -v to the
>>> gcc options and saw that it crashes right before it prints out its
>>> commandline arguments and environmental information. I managed to fix
>>> the problem by going back to ENV = os.environ. After a minute, and
>>> thinking back to the man page, the problem is obvious: your fix
>>> overwrites all the other environmental variables.
>>>
>>> Committed those two fixes.
>>>
>>> I can't figure out why at the moment, but the gfx commandline option
>>> doesn't cause gver.txt to change.
>> what happens if you quote it?
>>
>>> build/gver.txt appears to be a copy
>>> of gver.txt: it has the same modified time. For this reason, building
>>> anything other than the default backends either fails to link or
>>> doesn't let me run them.
>> Dependency bug.
>>
>>>
>>> I see you added a rule to force gcc to be used for .c files. However,
>>> audwrap is built completely differently, and you create an environment
>>> for its build where you don't set CC and CXX, so it tries to run VC++.
>>
>>> I can't understand why you created another environment for it, so I
>>> left this problem for you to fix.
>>>
>>> Switching from extra_env to env , I get:
>>> g++ -c build\audwrap\audwrap.cpp -o build\audwrap\audwrap.o -c -g -O3
>>> build\audwrap\audwrap.cpp:9:21: error: audwrap.h: No such file or directory
>> dependency bug. Easily fixed.
>>
>>>
>>> OK, now the killer problem: it doesn't rebuild anything when I edit a
>>> file!!
>>> Even if I run scons -c, it doesn't rebuild anything afterwards
>>> (but maybe -c is completely unsupported?)
>> -c works fine for me.
>> Did you change the *content*, not just edit something in and out again?
>>
>>>I still haven't tested on
>>> Linux. Is rebuilding working for you?
>> Certainly.
>>
>>>
>>> Also, any reason to not place built executables in wip/ instead of
>>> wip/build? It probably more common in other projects, but we already
>>> have all the dlls there, and various distribution scripts which assume
>>> that location.
>> Nope, I just thought it was not suitable.but, changed locally.
>> _______________________________________________
>> Ohrrpgce mailing list
>> [email protected]
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to