Re: [Warzone-dev] 570 patch?
Am Mittwoch, 27. Dezember 2006 06:31 schrieb [EMAIL PROTECTED]: > Posted by Dennis Schridde on December 26, 2006 - 20:56: > > - offset.x = (tileTexInfo[tileNumber & TILE_NUMMASK].xOffset > * 64); > > + offset.x = (UWORD)(tileTexInfo[tileNumber & > TILE_NUMMASK].u)*(UWORD)(-1); // FIXME HACK to wrap a float into a > UWORD > > Can you clarify why you think you need to use floats instead of > ints? That is a ugly hack as you say. AFAIK GL uses float for UV coordinates... If you know something different, you should mail the GL guys so they can update their docs... And as I said especially that (UDWORD)(-1) doesn't make any sense, I know that. Actually I was playing around with intersting casts at that time and not anymore really working on the original problem. ;) > Rest of the changes confuses me also. What is point of all this? > It doesn't really make it easier to understand, nor is the code > faster IMO, but maybe it is just me? As I said, that code may be crappy. It was late in the night and my first attempt to support tile resolutions different from 128x128 and I didn't have any knowledge of the code or it's context... What does this have to do with "570 patch"??? And please: Next time if I say that a patch is at least partly crappy and I only send it because it was requested (it helps at least to find the codeparts which need to be worked on IMHO), please respect that and don't tell me that I do crap. If I allready said that, one might think that I allready know that this was not my best work... --Dennis pgp4oj2Y43NhB.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
This patch does NOT apply, could you please resend it? I guess this is because of the line endings you also patched. --Dennis pgpf8oe3BfE84.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r569 - in /trunk: src/keybind.c
- Original Message - From: "Giel van Schijndel" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 27, 2006 1:19 AM Subject: [Warzone-dev] Re: [Warzone-commits] r569 - in /trunk: src/keybind.c Roman schreef: Author: troman Date: Tue Dec 26 17:39:07 2006 New Revision: 569 URL: http://svn.gna.org/viewcvs/warzone?rev=569&view=rev Log: -new 'height-map' radar mode (CTRL+TAB to cycle through radar modes) -revamped radar modes management Scripting engine: -some interpreter speedups -new script function to modify map tile height from scripts -made numeric pad keys 0-9 accessible from scripts Modified: ... trunk/src/keybind.c ... This revision breaks compilability of keybind.c. It uses an postfix operator ++ on an enum while an enum's basetype (e.g. int) is undefined and therefore doesn't have such an operator. Attached a very simple patch to fix this one. -- Giel Actually unlike in C++ using postfix increment on enum is perfectly legal in C and it doesn't even go outside of the last value in this particular implementation, so there shouldn't be problems. But if that breaks any compiler we should of course get rid of that. ;-) Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS installer
Am Mittwoch, 27. Dezember 2006 04:27 schrieb Giel van Schijndel:
> Dennis Schridde schreef:
> > Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel:
> >> Christian Ohm schreef:
> >>> On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote:
> * added some DLLs
> (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll,
> vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll)
> ( *NOTE: I'm afraight that the current installer executable you're
> distributing won't work without these DLLs* )
> >>>
> >>> What current installer? The one you can download from gna.org for 2.0.5
> >>> works on a system that has never seen Warzone before (but perhaps
> >>> you're talking about something else, and I'm too tired to notice).
> >>
> >> Nah, it apparently was me who was/is too tired to notice (CET=GMT+1
> >> here, so calculate it if you wish).
> >>
> >> It seems that that executable is statically linked to these libraries.
> >
> > Exactly. :)
> > Some ppl said that they didn't like all those DLLs in the folder, they
> > are not needed anyway, since probably never more than 1 app will use our
> > compilation of libpng or whatever and it saves some download space, so I
> > linked statically...
> >
> > Besides that the nsis patch looks ok, just one question: Why do you
> > sometimes use $DEVDIR and other times .. ?
> > Is it possible to pass variables to makensis? That way we could pass the
> > version info...
>
> ${DEVDIR} is a commandline passed variable, it is taken from DEVDIR in
> makerules/config.mk
> The reason I use ${DEVDIR} is because those files (or its sources for
> that matter) aren't contained in the repository (refers to the
> WZ-devpackage directory).
>
> The places where ../ is used is where the file is to be found in the
> repository or compiled from it.
>
> And yes it is indeed possible to pass variables to makensis just use
> "/Dvarname=value". Make sure to include it in quotes as shown though
> because it otherwise can't deal with spaces at all. Then inside the
> script refer to that value like this: ${varname}.
>
> As for version info you could use this (except the current comment that
> is): VIProductVersion "9.9.9.9" ; Version number provided here
> has to be in n.n.n.n format where n is any unsigned integer
> VIAddVersionKey "CompanyName" "Warzone Resurrection Project"
> VIAddVersionKey "FileDescription" "Warzone 2100 Installer"
> VIAddVersionKey "FileVersion" "TRUNK"
> VIAddVersionKey "InternalName" "Warzone 2100"
> VIAddVersionKey "LegalCopyright""© 2006 Warzone Resurrection
> Project"
> VIAddVersionKey "ProductName" "Warzone 2100"
> VIAddVersionKey "ProductVersion""TRUNK"
> VIAddVersionKey "Comments" "LALALALALALALA"
What do you think about this?
http://nsis.sourceforge.net/Version_Info_manipulations_on_compile-time
He seems to produce an .rc from an allready compiled .exe, but we allready got
the .rc, so we could skip all that reshacker stuff. I still don't exactly
know how it works, though. :(
--Dennis
pgpO8LU3dloH0.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Dennis Schridde schreef:
> This patch does NOT apply, could you please resend it?
> I guess this is because of the line endings you also patched.
>
Had to check the RFC822 `In-Reply-To' header to be sure you meant the
NSIS one.
But anyway here it is.
Just been awake for an hour or so, so I hope my double checking for
applicability was thorough enough.
--
Giel
Index: nsis/warzone2100.nsi
===
--- nsis/warzone2100.nsi(revision 573)
+++ nsis/warzone2100.nsi(working copy)
@@ -12,7 +12,7 @@
;Name and file
Name "Warzone 2100"
- OutFile "Warzone 2100.exe"
+ OutFile "${OUTFILE}"
;Default installation folder
InstallDir "$PROGRAMFILES\Warzone 2100"
@@ -75,8 +75,8 @@
;
;License Language String
- LicenseLangString MUILicense ${LANG_ENGLISH} "data\License.txt"
- LicenseLangString MUILicense ${LANG_GERMAN} "data\License.txt"
+ LicenseLangString MUILicense ${LANG_ENGLISH} "..\COPYING"
+ LicenseLangString MUILicense ${LANG_GERMAN} "..\COPYING"
;
;Reserve Files
@@ -100,28 +100,50 @@
;ADD YOUR OWN FILES HERE...
- File "data\warzone2100.exe"
- File "data\OpenAL32.dll"
- File "data\wrap_oal.dll"
- File "data\mp.wz"
- File "data\warzone.wz"
+ ; Main executable
+ File "..\src\warzone2100.exe"
- File "data\License.txt"
- File "data\Readme.txt"
+ ; Required runtime libs
+ File "${DEVDIR}\lib\SDL.dll"
+ File "${DEVDIR}\lib\SDL_net.dll"
+ File "${DEVDIR}\lib\physfs.dll"
+ File "${DEVDIR}\lib\vorbisfile.dll"
+ File "${DEVDIR}\lib\ogg.dll"
+ File "${DEVDIR}\lib\vorbis.dll"
+ File "${DEVDIR}\lib\png13.dll"
+ File "${DEVDIR}\lib\zlib1.dll"
+ File "${DEVDIR}\lib\jpeg6b.dll"
+ File "${DEVDIR}\lib\OpenAL32.dll"
+ File "${DEVDIR}\lib\wrap_oal.dll"
+ ; Data files
+ File "..\data\mp.wz"
+ File "..\data\warzone.wz"
+ ; Information/documentation files
+ File "/oname=License.txt" "..\COPYING"
+ File "/oname=Readme.txt" "..\README"
+
+
;Store installation folder
WriteRegStr HKCU "Software\Warzone 2100" "" $INSTDIR
- ;Create uninstaller
- WriteUninstaller "$INSTDIR\Uninstall.exe"
+ ; Write the Windows-uninstall keys and create the uninstaller
+ WriteRegStr HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100"
"DisplayName" "Warzone 2100"
+ WriteRegStr HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100"
"DisplayIcon" "$INSTDIR\warzone2100.exe,0"
+ WriteRegStr HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100" "Publisher"
"Warzone Resurrection Project"
+; WriteRegStr HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100"
"DisplayVersion" "2.0.5 r571"
+ WriteRegStr HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100"
"UninstallString" '"$INSTDIR\uninstall.exe"'
+ WriteRegDWORD HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100" "NoModify" 1
+ WriteRegDWORD HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100" "NoRepair" 1
+ WriteUninstaller "uninstall.exe"
!insertmacro MUI_STARTMENU_WRITE_BEGIN Application
;Create shortcuts
CreateDirectory "$SMPROGRAMS\$STARTMENU_FOLDER"
-CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk"
"$INSTDIR\Uninstall.exe"
-CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Warzone 2100.lnk"
"$INSTDIR\Warzone2100.exe"
+CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk"
"$INSTDIR\uninstall.exe"
+CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Warzone 2100.lnk"
"$INSTDIR\warzone2100.exe"
!insertmacro MUI_STARTMENU_WRITE_END
@@ -134,7 +156,7 @@
SetOutPath "$INSTDIR\mods\global"
- File "data\grim.wz"
+ File "..\data\grim.wz"
SetOutPath "$INSTDIR"
@@ -210,6 +232,15 @@
;ADD YOUR OWN FILES HERE...
Delete "$INSTDIR\warzone2100.exe"
+ Delete "$INSTDIR\SDL.dll"
+ Delete "$INSTDIR\SDL_net.dll"
+ Delete "$INSTDIR\physfs.dll"
+ Delete "$INSTDIR\vorbisfile.dll"
+ Delete "$INSTDIR\ogg.dll"
+ Delete "$INSTDIR\vorbis.dll"
+ Delete "$INSTDIR\png13.dll"
+ Delete "$INSTDIR\zlib1.dll"
+ Delete "$INSTDIR\jpeg6b.dll"
Delete "$INSTDIR\OpenAL32.dll"
Delete "$INSTDIR\wrap_oal.dll"
Delete "$INSTDIR\warzone.wz"
@@ -218,7 +249,7 @@
Delete "$INSTDIR\Readme.txt"
Delete "$INSTDIR\License.txt"
- Delete "$INSTDIR\Uninstall.exe"
+ Delete "$INSTDIR\uninstall.exe"
Delete "$INSTDIR\mods\global\grim.wz"
@@ -249,6 +280,9 @@
DeleteRegValue HKCU "Software\Warzone 2100" ""
DeleteRegKey /ifempty HKCU "Software\Warzone 2100"
+ ; Unregister with Windows' uninstall system
+ DeleteRegKey HKCU
"Software\Microsoft\Windows\CurrentVersion\Uninstall\Warzone 2100"
+
SectionEnd
;
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.g
Re: [Warzone-dev] NSIS installer
Dennis Schridde schreef:
> Am Mittwoch, 27. Dezember 2006 04:27 schrieb Giel van Schijndel:
>
>> ${DEVDIR} is a commandline passed variable, it is taken from DEVDIR in
>> makerules/config.mk
>> The reason I use ${DEVDIR} is because those files (or its sources for
>> that matter) aren't contained in the repository (refers to the
>> WZ-devpackage directory).
>>
>> The places where ../ is used is where the file is to be found in the
>> repository or compiled from it.
>>
>> And yes it is indeed possible to pass variables to makensis just use
>> "/Dvarname=value". Make sure to include it in quotes as shown though
>> because it otherwise can't deal with spaces at all. Then inside the
>> script refer to that value like this: ${varname}.
>>
>> As for version info you could use this (except the current comment that
>> is): VIProductVersion "9.9.9.9" ; Version number provided here
>> has to be in n.n.n.n format where n is any unsigned integer
>> VIAddVersionKey "CompanyName" "Warzone Resurrection Project"
>> VIAddVersionKey "FileDescription" "Warzone 2100 Installer"
>> VIAddVersionKey "FileVersion" "TRUNK"
>> VIAddVersionKey "InternalName" "Warzone 2100"
>> VIAddVersionKey "LegalCopyright""© 2006 Warzone Resurrection
>> Project"
>> VIAddVersionKey "ProductName" "Warzone 2100"
>> VIAddVersionKey "ProductVersion""TRUNK"
>> VIAddVersionKey "Comments" "LALALALALALALA"
>>
> What do you think about this?
> http://nsis.sourceforge.net/Version_Info_manipulations_on_compile-time
>
> He seems to produce an .rc from an allready compiled .exe, but we allready
> got
> the .rc, so we could skip all that reshacker stuff. I still don't exactly
> know how it works, though. :(
Looks very promising, I'll look into it.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Am Mittwoch, 27. Dezember 2006 15:05 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > This patch does NOT apply, could you please resend it? > > I guess this is because of the line endings you also patched. > > Had to check the RFC822 `In-Reply-To' header to be sure you meant the > NSIS one. > But anyway here it is. > > Just been awake for an hour or so, so I hope my double checking for > applicability was thorough enough. Weird... It still fails completely. But now I am at least able to apply it manually... pgpePhn6ZUGYP.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 15:05 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> This patch does NOT apply, could you please resend it? >>> I guess this is because of the line endings you also patched. >>> >> Had to check the RFC822 `In-Reply-To' header to be sure you meant the >> NSIS one. >> But anyway here it is. >> >> Just been awake for an hour or so, so I hope my double checking for >> applicability was thorough enough. >> > Weird... It still fails completely. But now I am at least able to apply it > manually... Hmm, done some checking between the mail I've send to the mailing list and received back. It seems that the mailing list adds some empty lines in between of the patch file and also modifies some rfc822 headers, this causes both the GPG signature to be invalid and the patch to fail application. Simply removing empty line number 114 should pull the trick in applicability. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Am Mittwoch, 27. Dezember 2006 15:47 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 15:05 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> This patch does NOT apply, could you please resend it? > >>> I guess this is because of the line endings you also patched. > >> > >> Had to check the RFC822 `In-Reply-To' header to be sure you meant the > >> NSIS one. > >> But anyway here it is. > >> > >> Just been awake for an hour or so, so I hope my double checking for > >> applicability was thorough enough. > > > > Weird... It still fails completely. But now I am at least able to apply > > it manually... > > Hmm, done some checking between the mail I've send to the mailing list > and received back. It seems that the mailing list adds some empty lines > in between of the patch file and also modifies some rfc822 headers, this > causes both the GPG signature to be invalid and the patch to fail > application. Simply removing empty line number 114 should pull the trick > in applicability. Did it manually now. One further idea: You use $OUTFILE... Maybe we could use something like $APPNAME="Warzone 2100" instead and use it in more than one place? Maybe also $SHORTAPPNAME="warzone2100" and $VERSION="2.0.5" would concat to an OutFile of "warzone2100-2.0.5.exe"? pgpHzxD67bTAv.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r576 - in /trunk/nsis: Makefile.raw warzone2100.nsi
Dennis Schridde schreef:
> Author: devurandom
> Date: Wed Dec 27 16:48:28 2006
> New Revision: 576
>
> URL: http://svn.gna.org/viewcvs/warzone?rev=576&view=rev
> Log:
> - Modify NSIS script to support more flexible directory structures
> - Use external version definition
>
> Modified:
> trunk/nsis/Makefile.raw
> trunk/nsis/warzone2100.nsi
>
These modifications do not work with the current
makerules/config.mk.tmpl where VERSION is defined as \"n.n.n\" because
these quotation-marks get directly copied into the NSIS script.
Example:
makerules/config.mk:
VERSION=\"2.0.5\"
NSIS-code (line 15):
OutFile "warzone2100-${VERSION}.exe"
resulting NSIS-code:
OutFile "warzone2100-"2.0.5".exe"
And because of these quotation-marks it interprets that string as two
parameters to OutFile which only accepts one parameter: result=error.
So to fix this, attached patch modifies the build-system in a very small
way (i.e. simply changing the way VERSION is declared in the
makerules/config.mk makefile).
--
Giel
Index: makerules/config.mk.tmpl
===
--- makerules/config.mk.tmpl(revision 576)
+++ makerules/config.mk.tmpl(working copy)
@@ -1,5 +1,5 @@
# Version of Warzone you are compiling
-#VERSION=\"0.0.0\"
+#VERSION=0.0.0
# Platform you are running
#PLATFORM=windows
Index: makerules/configure.mk
===
--- makerules/configure.mk (revision 576)
+++ makerules/configure.mk (working copy)
@@ -48,7 +48,7 @@
# Setup paths and static values
-CFLAGS+=-m32 -DVERSION=$(VERSION) -DYY_STATIC -I.. -I../.. -I$(DEVDIR)/include
+CFLAGS+=-m32 -DVERSION=\"$(VERSION)\" -DYY_STATIC -I.. -I../..
-I$(DEVDIR)/include
LDFLAGS+=-L$(DEVDIR)/lib
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS installer
Giel van Schijndel schreef:
> Dennis Schridde schreef:
>
>> Am Mittwoch, 27. Dezember 2006 04:27 schrieb Giel van Schijndel:
>>
>>
>>> ${DEVDIR} is a commandline passed variable, it is taken from DEVDIR in
>>> makerules/config.mk
>>> The reason I use ${DEVDIR} is because those files (or its sources for
>>> that matter) aren't contained in the repository (refers to the
>>> WZ-devpackage directory).
>>>
>>> The places where ../ is used is where the file is to be found in the
>>> repository or compiled from it.
>>>
>>> And yes it is indeed possible to pass variables to makensis just use
>>> "/Dvarname=value". Make sure to include it in quotes as shown though
>>> because it otherwise can't deal with spaces at all. Then inside the
>>> script refer to that value like this: ${varname}.
>>>
>>> As for version info you could use this (except the current comment that
>>> is): VIProductVersion "9.9.9.9" ; Version number provided here
>>> has to be in n.n.n.n format where n is any unsigned integer
>>> VIAddVersionKey "CompanyName" "Warzone Resurrection Project"
>>> VIAddVersionKey "FileDescription" "Warzone 2100 Installer"
>>> VIAddVersionKey "FileVersion" "TRUNK"
>>> VIAddVersionKey "InternalName" "Warzone 2100"
>>> VIAddVersionKey "LegalCopyright""© 2006 Warzone Resurrection
>>> Project"
>>> VIAddVersionKey "ProductName" "Warzone 2100"
>>> VIAddVersionKey "ProductVersion""TRUNK"
>>> VIAddVersionKey "Comments" "LALALALALALALA"
>>>
>>>
>> What do you think about this?
>> http://nsis.sourceforge.net/Version_Info_manipulations_on_compile-time
>>
>> He seems to produce an .rc from an allready compiled .exe, but we allready
>> got
>> the .rc, so we could skip all that reshacker stuff. I still don't exactly
>> know how it works, though. :(
>>
> Looks very promising, I'll look into it.
Now it doesn't look as promising as I initially thought it did.
Yes, it does extract the .rc from the .exe using ResHacker this only to
do some string processing to retrieve the version number.
The second part is used to retrieve a .res file from the .exe (windres
produces a .res also if you want by compiling a .rc file).
So both of these two things we could do without using ResHacker.
What it does then however is using ResHacker to produce the EXE header
(contains all the windows resource stuff). And besides that this is a
truly unreliable way of incorporating your version information into the
final executable. It also depends on an external tool not part of NSIS
while NSIS itself can do the job, i.e. using all those VIAddVersionKey
statements, and as such adding more complexity to the required toolchain
needlessly.
So my vote goes for simply using the VIAddVersionKey statement in
combination with the command line definitions ${VERSION} and ${VERSIONNUM}.
PS I notice that the last patch doesn't yet fully comply with the
VIProductVersion statement (which requires a string in x.x.x.x format as
parameter). So attached one should fix this as well.
--
Giel
Index: makerules/config.mk.tmpl
===
--- makerules/config.mk.tmpl(revision 576)
+++ makerules/config.mk.tmpl(working copy)
@@ -1,5 +1,7 @@
# Version of Warzone you are compiling
-#VERSION=\"0.0.0\"
+#VERSION=0.0.0
+# Version in x.x.x.x format
+#VERSIONNUM=0.0.0.0
# Platform you are running
#PLATFORM=windows
Index: makerules/configure.mk
===
--- makerules/configure.mk (revision 576)
+++ makerules/configure.mk (working copy)
@@ -48,7 +48,7 @@
# Setup paths and static values
-CFLAGS+=-m32 -DVERSION=$(VERSION) -DYY_STATIC -I.. -I../.. -I$(DEVDIR)/include
+CFLAGS+=-m32 -DVERSION=\"$(VERSION)\" -DYY_STATIC -I.. -I../..
-I$(DEVDIR)/include
LDFLAGS+=-L$(DEVDIR)/lib
Index: nsis/Makefile.raw
===
--- nsis/Makefile.raw (revision 576)
+++ nsis/Makefile.raw (working copy)
@@ -8,7 +8,7 @@
all: $(SETUPFILE)
$(SETUPFILE): warzone2100.nsi ../src/warzone2100.exe ../data/warzone.wz
../data/mp.wz ../data/grim.wz
- makensis "/DVERSION=$(VERSION)" "/DVERSIONNUM=$(VERSION)"
"/DLIBDIR=$(DEVDIR)\lib" "/DSRCDIR=..\src" "/DDATADIR=..\data" "/DMISCDIR=.." $<
+ makensis "/DVERSION=$(VERSION)" "/DVERSIONNUM=$(VERSIONNUM)"
"/DLIBDIR=$(DEVDIR)\lib" "/DSRCDIR=..\src" "/DDATADIR=..\data" "/DMISCDIR=.." $<
clean:
$(RM) $(SETUPFILE)
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel: > >> Christian Ohm schreef: >> >>> On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote: >>> * added some DLLs (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll, vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll) ( *NOTE: I'm afraight that the current installer executable you're distributing won't work without these DLLs* ) >>> What current installer? The one you can download from gna.org for 2.0.5 >>> works on a system that has never seen Warzone before (but perhaps you're >>> talking about something else, and I'm too tired to notice). >>> >> Nah, it apparently was me who was/is too tired to notice (CET=GMT+1 >> here, so calculate it if you wish). >> >> It seems that that executable is statically linked to these libraries. >> > Exactly. :) > Some ppl said that they didn't like all those DLLs in the folder, they are > not > needed anyway, since probably never more than 1 app will use our compilation > of libpng or whatever and it saves some download space, so I linked > statically... > I assume that you've modified the warzone devpackage for that ( this one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), would you care to upload the version you're using there? That'd be much appreciated (i.e. by me for one thing). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel: > >> Christian Ohm schreef: > >>> On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote: > * added some DLLs > (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll, > vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll) > ( *NOTE: I'm afraight that the current installer executable you're > distributing won't work without these DLLs* ) > >>> > >>> What current installer? The one you can download from gna.org for 2.0.5 > >>> works on a system that has never seen Warzone before (but perhaps > >>> you're talking about something else, and I'm too tired to notice). > >> > >> Nah, it apparently was me who was/is too tired to notice (CET=GMT+1 > >> here, so calculate it if you wish). > >> > >> It seems that that executable is statically linked to these libraries. > > > > Exactly. :) > > Some ppl said that they didn't like all those DLLs in the folder, they > > are not needed anyway, since probably never more than 1 app will use our > > compilation of libpng or whatever and it saves some download space, so I > > linked statically... > > I assume that you've modified the warzone devpackage for that ( this > one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), > would you care to upload the version you're using there? Allready done, just didn't announce it yet. (MSVC package is not yet uploaded.) http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. --Dennis pgp1SgSFzlCFw.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Dennis Schridde schreef:
> Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel:
>
>> Dennis Schridde schreef:
>>
>>> Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel:
>>>
Christian Ohm schreef:
> On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote:
>
>> * added some DLLs
>> (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll,
>> vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll)
>> ( *NOTE: I'm afraight that the current installer executable you're
>> distributing won't work without these DLLs* )
>>
> What current installer? The one you can download from gna.org for 2.0.5
> works on a system that has never seen Warzone before (but perhaps
> you're talking about something else, and I'm too tired to notice).
>
Nah, it apparently was me who was/is too tired to notice (CET=GMT+1
here, so calculate it if you wish).
It seems that that executable is statically linked to these libraries.
>>> Exactly. :)
>>> Some ppl said that they didn't like all those DLLs in the folder, they
>>> are not needed anyway, since probably never more than 1 app will use our
>>> compilation of libpng or whatever and it saves some download space, so I
>>> linked statically...
>>>
>> I assume that you've modified the warzone devpackage for that ( this
>> one: http://download.gna.org/warzone/development/warzone-devpkg.7z ),
>> would you care to upload the version you're using there?
>>
> Allready done, just didn't announce it yet. (MSVC package is not yet
> uploaded.)
> http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z
>
> The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg.
>
Well that new MinGW devpackage doesn't work all to nice. It gives me a
whole bunch of png related compiler errors.
> g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../..
> -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows
> -DWIN32 -c -opcx.o pcx.c
> In file included from pcx.c:1:
> C:/devpkg/include/png.h:1: error: expected constructor, destructor, or
> type conversion before '/' token
> C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token
> In file included from pcx.c:1:
> C:/devpkg/include/png.h:1:15: warning: no newline at end of file
> pcx.c:12: error: `png_size_t' does not name a type
> pcx.c:16: error: variable or field `wzpng_read_data' declared void
> pcx.c:16: error: `png_structp' was not declared in this scope
> pcx.c:16: error: `png_bytep' was not declared in this scope
> pcx.c:16: error: `png_size_t' was not declared in this scope
> pcx.c:17: warning: initializer expression list treated as compound
> expression
> pcx.c:17: error: expected `,' or `;' before '{' token
> pcx.c: In function `BOOL pie_PNGLoadMem(char*, iSprite*, iColour*)':
> pcx.c:31: error: `png_structp' undeclared (first use this function)
> pcx.c:31: error: (Each undeclared identifier is reported only once for
> each func
> tion it appears in.)
> pcx.c:31: error: expected `;' before "png_ptr"
> pcx.c:32: error: `png_infop' undeclared (first use this function)
> pcx.c:32: error: expected `;' before "info_ptr"
> pcx.c:38: error: 'struct wzpng_io_buf' has no member named 'length'
> pcx.c:42: error: `png_byte' undeclared (first use this function)
> pcx.c:42: error: expected primary-expression before ')' token
> pcx.c:42: error: `png_size_t' undeclared (first use this function)
> pcx.c:42: error: `png_sig_cmp' undeclared (first use this function)
> pcx.c:47: error: `png_ptr' undeclared (first use this function)
> pcx.c:47: error: `PNG_LIBPNG_VER_STRING' undeclared (first use this
> function)
> pcx.c:48: error: `png_create_read_struct' undeclared (first use this
> function)
> pcx.c:55: error: `info_ptr' undeclared (first use this function)
> pcx.c:55: error: `png_create_info_struct' undeclared (first use this
> function)
> pcx.c:62: error: `png_jmpbuf' undeclared (first use this function)
> pcx.c:62: error: `_setjmp' undeclared (first use this function)
> pcx.c:67: error: `png_uint_32' undeclared (first use this function)
> pcx.c:67: error: expected `;' before "width"
> pcx.c:70: error: `png_set_read_fn' undeclared (first use this function)
> pcx.c:73: error: `png_read_info' undeclared (first use this function)
> pcx.c:74: error: `width' undeclared (first use this function)
> pcx.c:74: error: `height' undeclared (first use this function)
> pcx.c:75: error: `png_get_IHDR' undeclared (first use this function)
> pcx.c:78: error: `png_set_strip_16' undeclared (first use this function)
> pcx.c:83: error: `png_set_packing' undeclared (first use this function)
> pcx.c:86: error: `png_set_gray_to_rgb' undeclared (first use this
> function)
> pcx.c:87: error: `png_set_palette_to_rgb' undeclared (first use this
> function)
> pcx.c:88: error: `png_set_tRNS_to_alpha' undeclared (first use this
> function)
> pcx.c:89: error: `P
Re: [Warzone-dev] 2.0.5 released
Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel: > Christian Ohm schreef: > > On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote: > >> * added some DLLs > >> (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll, > >> vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll) > >> ( *NOTE: I'm afraight that the current installer executable > >> you're distributing won't work without these DLLs* ) > > > > What current installer? The one you can download from gna.org for > > 2.0.5 works on a system that has never seen Warzone before (but > > perhaps you're talking about something else, and I'm too tired to > > notice). > > Nah, it apparently was me who was/is too tired to notice (CET=GMT+1 > here, so calculate it if you wish). > > It seems that that executable is statically linked to these libraries. > >>> > >>> Exactly. :) > >>> Some ppl said that they didn't like all those DLLs in the folder, they > >>> are not needed anyway, since probably never more than 1 app will use > >>> our compilation of libpng or whatever and it saves some download space, > >>> so I linked statically... > >> > >> I assume that you've modified the warzone devpackage for that ( this > >> one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), > >> would you care to upload the version you're using there? > > > > Allready done, just didn't announce it yet. (MSVC package is not yet > > uploaded.) > > http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z > > > > The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. > > Well that new MinGW devpackage doesn't work all to nice. It gives me a > whole bunch of png related compiler errors. > > > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > > -DWIN32 -c -opcx.o pcx.c > > In file included from pcx.c:1: > > C:/devpkg/include/png.h:1: error: expected constructor, destructor, or > > type conversion before '/' token > > C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token > > In file included from pcx.c:1: > > C:/devpkg/include/png.h:1:15: warning: no newline at end of file Did you have a look at that png.h? Could it be related to DOS/UNIX lineendings? pgpI5N7fOCbv6.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
2.05 wouldn't happen to be in portage for gentoo would it?? bc i have no clue how to install the autopackage lmao.. On 12/27/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> Am Mittwoch, 27. Dezember 2006 02:50 schrieb Giel van Schijndel: > Christian Ohm schreef: > > On Wednesday, 27 December 2006 at 1:46, Giel van Schijndel wrote: > >> * added some DLLs > >> (SDL.dll, SDL_net.dll, physfs.dll, vorbisfile.dll, ogg.dll, > >> vorbis.dll, png13.dll, zlib1.dll, jpeg6b.dll) > >> ( *NOTE: I'm afraight that the current installer executable > >> you're distributing won't work without these DLLs* ) > > > > What current installer? The one you can download from gna.org for > > 2.0.5 works on a system that has never seen Warzone before (but > > perhaps you're talking about something else, and I'm too tired to > > notice). > > Nah, it apparently was me who was/is too tired to notice (CET=GMT+1 > here, so calculate it if you wish). > > It seems that that executable is statically linked to these libraries. > >>> > >>> Exactly. :) > >>> Some ppl said that they didn't like all those DLLs in the folder, they > >>> are not needed anyway, since probably never more than 1 app will use > >>> our compilation of libpng or whatever and it saves some download space, > >>> so I linked statically... > >> > >> I assume that you've modified the warzone devpackage for that ( this > >> one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), > >> would you care to upload the version you're using there? > > > > Allready done, just didn't announce it yet. (MSVC package is not yet > > uploaded.) > > http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z > > > > The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. > > Well that new MinGW devpackage doesn't work all to nice. It gives me a > whole bunch of png related compiler errors. > > > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > > -DWIN32 -c -opcx.o pcx.c > > In file included from pcx.c:1: > > C:/devpkg/include/png.h:1: error: expected constructor, destructor, or > > type conversion before '/' token > > C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token > > In file included from pcx.c:1: > > C:/devpkg/include/png.h:1:15: warning: no newline at end of file Did you have a look at that png.h? Could it be related to DOS/UNIX lineendings? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev -- Karma, It's Real! "No penguins were harmed during the writing, just a bunch of broken windows to let them escape..."-xtacocorex ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
2006/12/27, Daemon Xavier <[EMAIL PROTECTED]>: 2.05 wouldn't happen to be in portage for gentoo would it?? bc i have no clue how to install the autopackage lmao.. You just execute the autopackage file, and it'll launch an installer. -- Venlig hilsen / Kind regards, Christian Vest Hansen. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.5 released
Am Mittwoch, 27. Dezember 2006 19:25 schrieb Daemon Xavier: > 2.05 wouldn't happen to be in portage for gentoo would it?? bc i have no > clue how to install the autopackage lmao.. It is allready in portage, according to my eix... Installing the AutoPackage is easy: "sh warzone2100-2.0.5.package" The rest is handled by the GTK (or ncurses if you lack gtk) GUI. --Dennis pgps0NtsChhEm.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS installer
Am Mittwoch, 27. Dezember 2006 17:45 schrieb Giel van Schijndel:
> Giel van Schijndel schreef:
> > Dennis Schridde schreef:
> >> Am Mittwoch, 27. Dezember 2006 04:27 schrieb Giel van Schijndel:
> >>> ${DEVDIR} is a commandline passed variable, it is taken from DEVDIR in
> >>> makerules/config.mk
> >>> The reason I use ${DEVDIR} is because those files (or its sources for
> >>> that matter) aren't contained in the repository (refers to the
> >>> WZ-devpackage directory).
> >>>
> >>> The places where ../ is used is where the file is to be found in the
> >>> repository or compiled from it.
> >>>
> >>> And yes it is indeed possible to pass variables to makensis just use
> >>> "/Dvarname=value". Make sure to include it in quotes as shown though
> >>> because it otherwise can't deal with spaces at all. Then inside the
> >>> script refer to that value like this: ${varname}.
> >>>
> >>> As for version info you could use this (except the current comment that
> >>> is): VIProductVersion "9.9.9.9" ; Version number provided
> >>> here has to be in n.n.n.n format where n is any unsigned integer
> >>> VIAddVersionKey "CompanyName" "Warzone Resurrection Project"
> >>> VIAddVersionKey "FileDescription" "Warzone 2100 Installer"
> >>> VIAddVersionKey "FileVersion" "TRUNK"
> >>> VIAddVersionKey "InternalName" "Warzone 2100"
> >>> VIAddVersionKey "LegalCopyright""© 2006 Warzone Resurrection
> >>> Project"
> >>> VIAddVersionKey "ProductName" "Warzone 2100"
> >>> VIAddVersionKey "ProductVersion""TRUNK"
> >>> VIAddVersionKey "Comments" "LALALALALALALA"
> >>
> >> What do you think about this?
> >> http://nsis.sourceforge.net/Version_Info_manipulations_on_compile-time
> >>
> >> He seems to produce an .rc from an allready compiled .exe, but we
> >> allready got the .rc, so we could skip all that reshacker stuff. I still
> >> don't exactly know how it works, though. :(
> >
> > Looks very promising, I'll look into it.
>
> Now it doesn't look as promising as I initially thought it did.
>
> Yes, it does extract the .rc from the .exe using ResHacker this only to
> do some string processing to retrieve the version number.
>
> The second part is used to retrieve a .res file from the .exe (windres
> produces a .res also if you want by compiling a .rc file).
>
> So both of these two things we could do without using ResHacker.
> What it does then however is using ResHacker to produce the EXE header
> (contains all the windows resource stuff). And besides that this is a
> truly unreliable way of incorporating your version information into the
> final executable. It also depends on an external tool not part of NSIS
> while NSIS itself can do the job, i.e. using all those VIAddVersionKey
> statements, and as such adding more complexity to the required toolchain
> needlessly.
:(
NSIS doesn't offer a way to extract something from a file? Eg grep-like?
--Dennis
pgpm9F5FFYecW.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] warzone devpackage
Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: >>> I assume that you've modified the warzone devpackage for that ( this one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), would you care to upload the version you're using there? >>> Allready done, just didn't announce it yet. (MSVC package is not yet >>> uploaded.) >>> http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z >>> >>> The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. >>> >> Well that new MinGW devpackage doesn't work all to nice. It gives me a >> whole bunch of png related compiler errors. >> >> >>> g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. >>> -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows >>> -DWIN32 -c -opcx.o pcx.c >>> In file included from pcx.c:1: >>> C:/devpkg/include/png.h:1: error: expected constructor, destructor, or >>> type conversion before '/' token >>> C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token >>> In file included from pcx.c:1: >>> C:/devpkg/include/png.h:1:15: warning: no newline at end of file >>> > Did you have a look at that png.h? > Could it be related to DOS/UNIX lineendings? No, GCC (and as such MinGW) doesn't care about line-endings as long as they're the same throughout the file. When looking at that last error message you quoted it also indicates a line number of 1, which suggests the last line is nrl 1. Meaning there is only one line there, so I went to watch there and this where its contents exactly: "libpng12/png.h" (without quotes). While it should (most likely) be this: #include "libpng12/png.h" So that's an easy fix, that fixes compiling. So now we're done compiling lets get trouble with linking. NOTE:all selected libraries are defined in makerules/config.mk (LDFLAGS) * -ljpeg6b cannot be found, I'm guessing -ljpeg should be used instead * -lpng13 cannot be found, if using -lpng instead it uses lib/libpng.a of which the linker says "lib/libpng.a: file format not recognized; treating as linker script" which of course fails miserably, so lets put my money on -lpng12 instead. But we're still having problems now: > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > -DWIN32 -o warzone2100.exe ai.o aiexperience.o astar.o action.o > advvis.o atmos.o bridge.o buildpos.o cdspan.o cheat.o cluster.o > cmddroid.o combat.o component.o console.o data.o design.o difficulty.o > disp2d.o display.o droid.o e3demo.o edit2d.o edit3d.o effects.o > environ.o fpath.o feature.o findpath.o formation.o frontend.o > gateway.o gatewayroute.o gatewaysup.o geometry.o group.o hci.o init.o > intdisplay.o intimage.o intorder.o intelmap.o keybind.o keymap.o > level_lexer.o levels.o lighting.o loop.o map.o mapdisplay.o mapgrid.o > mechanics.o message.o miscimd.o move.o multiint.o multimenu.o > multiopt.o multisync.o multibot.o multistat.o objmem.o objects.o > optimisepath.o order.o player.o powercrypt.o radar.o raycast.o > research.o scores.o scriptai.o scriptcb.o scriptextern.o scriptfuncs.o > scriptobj.o scripttabs.o scriptvals.o scriptvals_parser.o > scriptvals_lexer.o selection.o stats.o text.o texture.o transporter.o > visibility.o warcam.o wrappers.o ani.o arrow.o aud.o audio_id.o > bucket3d.o clparse.o configuration.o csnap.o display3d.o drive.o > function.o game.o ingameop.o keyedit.o loadsave.o main.o mission.o > multigifts.o multijoin.o multilimit.o multiplay.o multistruct.o > oprint.o power.o projectile.o seqdisp.o structure.o target.o > warzoneconfig.o ../lib/libframework.a ../lib/libgamelib.a > ../lib/libivis_common.a ../lib/libivis_opengl.a ../lib/libnetplay.a > ../lib/libscript.a ../lib/libsequence.a ../lib/libsound.a > ../lib/libwidget.a ../win32/warzone2100.o -LC:\devpkg/lib -lmingw32 > -lglu32 -lopengl32 -lopenal32 -ljpeg -lpng12 -lmad -lvorbisfile > -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net > > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x279):pngread.c: undefined > reference to `inflateInit_' > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x5b5):pngread.c: undefined > reference to `inflateInit_' > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x1283):pngread.c: undefined > reference to `inflate' > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x214d):pngread.c: undefined > reference to `inflateEnd' > C:\devpkg/lib/libpng12.a(png.o)(.text+0x1bc):png.c: undefined > reference to `crc32' > C:\devpkg/lib/libpng12.a(png.o)(.text+0x23b):png.c: undefined > reference to `crc32' > C:\devpkg/lib/libpng12.a(png.o)(.text+0xd29):png.c: undefined > reference to `inflateReset' > C:\devpkg/lib/libpng12.a(pngrutil.o)(.text+0x33d):pngrutil.c: > undefined reference to `inflate' > C:\devpkg/lib/libpng12.a(pngrutil.o)(.text+0x3a0):pngrutil.c: > undefined reference
Re: [Warzone-dev] 2.0.5 released
lol ok thx much, for some reason i was using run or something. On 12/27/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: Am Mittwoch, 27. Dezember 2006 19:25 schrieb Daemon Xavier: > 2.05 wouldn't happen to be in portage for gentoo would it?? bc i have no > clue how to install the autopackage lmao.. It is allready in portage, according to my eix... Installing the AutoPackage is easy: "sh warzone2100-2.0.5.package" The rest is handled by the GTK (or ncurses if you lack gtk) GUI. --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev -- Karma, It's Real! "No penguins were harmed during the writing, just a bunch of broken windows to let them escape..."-xtacocorex ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS installer
Dennis Schridde schreef:
> Am Mittwoch, 27. Dezember 2006 17:45 schrieb Giel van Schijndel:
>
>> Giel van Schijndel schreef:
>>
>>> Dennis Schridde schreef:
>>>
Am Mittwoch, 27. Dezember 2006 04:27 schrieb Giel van Schijndel:
> ${DEVDIR} is a commandline passed variable, it is taken from DEVDIR in
> makerules/config.mk
> The reason I use ${DEVDIR} is because those files (or its sources for
> that matter) aren't contained in the repository (refers to the
> WZ-devpackage directory).
>
> The places where ../ is used is where the file is to be found in the
> repository or compiled from it.
>
> And yes it is indeed possible to pass variables to makensis just use
> "/Dvarname=value". Make sure to include it in quotes as shown though
> because it otherwise can't deal with spaces at all. Then inside the
> script refer to that value like this: ${varname}.
>
> As for version info you could use this (except the current comment that
> is): VIProductVersion "9.9.9.9" ; Version number provided
> here has to be in n.n.n.n format where n is any unsigned integer
> VIAddVersionKey "CompanyName" "Warzone Resurrection Project"
> VIAddVersionKey "FileDescription" "Warzone 2100 Installer"
> VIAddVersionKey "FileVersion" "TRUNK"
> VIAddVersionKey "InternalName" "Warzone 2100"
> VIAddVersionKey "LegalCopyright""© 2006 Warzone Resurrection
> Project"
> VIAddVersionKey "ProductName" "Warzone 2100"
> VIAddVersionKey "ProductVersion""TRUNK"
> VIAddVersionKey "Comments" "LALALALALALALA"
>
What do you think about this?
http://nsis.sourceforge.net/Version_Info_manipulations_on_compile-time
He seems to produce an .rc from an allready compiled .exe, but we
allready got the .rc, so we could skip all that reshacker stuff. I still
don't exactly know how it works, though. :(
>>> Looks very promising, I'll look into it.
>>>
>> Now it doesn't look as promising as I initially thought it did.
>>
>> Yes, it does extract the .rc from the .exe using ResHacker this only to
>> do some string processing to retrieve the version number.
>>
>> The second part is used to retrieve a .res file from the .exe (windres
>> produces a .res also if you want by compiling a .rc file).
>>
>> So both of these two things we could do without using ResHacker.
>> What it does then however is using ResHacker to produce the EXE header
>> (contains all the windows resource stuff). And besides that this is a
>> truly unreliable way of incorporating your version information into the
>> final executable. It also depends on an external tool not part of NSIS
>> while NSIS itself can do the job, i.e. using all those VIAddVersionKey
>> statements, and as such adding more complexity to the required toolchain
>> needlessly.
>>
> :(
> NSIS doesn't offer a way to extract something from a file? Eg grep-like?
No, unless you're willing to write unreasonably large functions yourself
(e.g.
http://nsis.sourceforge.net/GetBetween:_Get_text_in_between_two_markers_in_a_file
). And regular expressions aren't supported AFAIK by NSIS
But even if you did add such functions, you'd need to interpret the
.rc-fileformat which currently is only the job of the compiler. And to
my opinion it should stay the job of the compiler and shouldn't become
that of us using some unacceptably large NSIS script. Then as a second
point, the only information that might change on a regular basis is
currently (i.e. in SVN) already defined using command line definitions
(i.e. ${VERSION} and ${VERSIONNUM}) so there isn't a requirement for
automation to my opinion anyway (at least not large enough to motivate
writing functions larger than 40 lines).
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] warzone devpackage
Am Mittwoch, 27. Dezember 2006 20:03 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > I assume that you've modified the warzone devpackage for that ( this > one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), > would you care to upload the version you're using there? > >>> > >>> Allready done, just didn't announce it yet. (MSVC package is not yet > >>> uploaded.) > >>> http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z > >>> > >>> The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. > >> > >> Well that new MinGW devpackage doesn't work all to nice. It gives me a > >> whole bunch of png related compiler errors. > >> > >>> g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > >>> -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > >>> -DWIN32 -c -opcx.o pcx.c > >>> In file included from pcx.c:1: > >>> C:/devpkg/include/png.h:1: error: expected constructor, destructor, or > >>> type conversion before '/' token > >>> C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token > >>> In file included from pcx.c:1: > >>> C:/devpkg/include/png.h:1:15: warning: no newline at end of file > > > > Did you have a look at that png.h? > > Could it be related to DOS/UNIX lineendings? > > No, GCC (and as such MinGW) doesn't care about line-endings as long as > they're the same throughout the file. > > When looking at that last error message you quoted it also indicates a > line number of 1, which suggests the last line is nrl 1. Meaning there > is only one line there, so I went to watch there and this where its > contents exactly: "libpng12/png.h" (without quotes). > While it should (most likely) be this: > #include "libpng12/png.h" The include/png.h in the devpkg you got only contains "libpng12/png.h" ??? That's very odd, since mine is a full featured C header... > So that's an easy fix, that fixes compiling. > > > So now we're done compiling lets get trouble with linking. > NOTE:all selected libraries are defined in makerules/config.mk (LDFLAGS) > > * -ljpeg6b cannot be found, I'm guessing -ljpeg should be used instead > * -lpng13 cannot be found, if using -lpng instead it uses lib/libpng.a > of which the linker says "lib/libpng.a: file format not recognized; > treating as linker script" which of course fails miserably, so lets put > my money on -lpng12 instead. I think it should be -lpng, without any version number... > But we're still having problems now: > > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > > -DWIN32 -o warzone2100.exe ai.o aiexperience.o astar.o action.o > > advvis.o atmos.o bridge.o buildpos.o cdspan.o cheat.o cluster.o > > cmddroid.o combat.o component.o console.o data.o design.o difficulty.o > > disp2d.o display.o droid.o e3demo.o edit2d.o edit3d.o effects.o > > environ.o fpath.o feature.o findpath.o formation.o frontend.o > > gateway.o gatewayroute.o gatewaysup.o geometry.o group.o hci.o init.o > > intdisplay.o intimage.o intorder.o intelmap.o keybind.o keymap.o > > level_lexer.o levels.o lighting.o loop.o map.o mapdisplay.o mapgrid.o > > mechanics.o message.o miscimd.o move.o multiint.o multimenu.o > > multiopt.o multisync.o multibot.o multistat.o objmem.o objects.o > > optimisepath.o order.o player.o powercrypt.o radar.o raycast.o > > research.o scores.o scriptai.o scriptcb.o scriptextern.o scriptfuncs.o > > scriptobj.o scripttabs.o scriptvals.o scriptvals_parser.o > > scriptvals_lexer.o selection.o stats.o text.o texture.o transporter.o > > visibility.o warcam.o wrappers.o ani.o arrow.o aud.o audio_id.o > > bucket3d.o clparse.o configuration.o csnap.o display3d.o drive.o > > function.o game.o ingameop.o keyedit.o loadsave.o main.o mission.o > > multigifts.o multijoin.o multilimit.o multiplay.o multistruct.o > > oprint.o power.o projectile.o seqdisp.o structure.o target.o > > warzoneconfig.o ../lib/libframework.a ../lib/libgamelib.a > > ../lib/libivis_common.a ../lib/libivis_opengl.a ../lib/libnetplay.a > > ../lib/libscript.a ../lib/libsequence.a ../lib/libsound.a > > ../lib/libwidget.a ../win32/warzone2100.o -LC:\devpkg/lib -lmingw32 > > -lglu32 -lopengl32 -lopenal32 -ljpeg -lpng12 -lmad -lvorbisfile > > -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net > > > > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x279):pngread.c: undefined > > reference to `inflateInit_' > > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x5b5):pngread.c: undefined > > reference to `inflateInit_' > > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x1283):pngread.c: undefined > > reference to `inflate' > > C:\devpkg/lib/libpng12.a(pngread.o)(.text+0x214d):pngread.c: undefined > > reference to `inflateEnd' > > C:\devpkg/lib/libpng12.a(png.o)(.text+0x1bc):png.c: undefined > > reference to `c
Re: [Warzone-dev] NSIS installer
Am Mittwoch, 27. Dezember 2006 20:14 schrieb Giel van Schijndel:
> Dennis Schridde schreef:
> > NSIS doesn't offer a way to extract something from a file? Eg grep-like?
>
> No, unless you're willing to write unreasonably large functions yourself
> (e.g.
> http://nsis.sourceforge.net/GetBetween:_Get_text_in_between_two_markers_in_
>a_file ). And regular expressions aren't supported AFAIK by NSIS
>
> But even if you did add such functions, you'd need to interpret the
> .rc-fileformat which currently is only the job of the compiler. And to
> my opinion it should stay the job of the compiler and shouldn't become
> that of us using some unacceptably large NSIS script. Then as a second
> point, the only information that might change on a regular basis is
> currently (i.e. in SVN) already defined using command line definitions
> (i.e. ${VERSION} and ${VERSIONNUM}) so there isn't a requirement for
Problem with those is that you can't create VERSIONNUM automatically out of
VERSION. This might be suitable for the raw Makefiles, but certainly is not
for the automake build...
As a workaround I added a --with-installer-version switch to configure.
--Dennis
pgpxfDzYqgYsW.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS installer
Dennis Schridde schreef:
> Am Mittwoch, 27. Dezember 2006 20:14 schrieb Giel van Schijndel:
>
>> Dennis Schridde schreef:
>>
>>> NSIS doesn't offer a way to extract something from a file? Eg grep-like?
>>>
>> No, unless you're willing to write unreasonably large functions yourself
>> (e.g.
>> http://nsis.sourceforge.net/GetBetween:_Get_text_in_between_two_markers_in_
>> a_file ). And regular expressions aren't supported AFAIK by NSIS
>>
>> But even if you did add such functions, you'd need to interpret the
>> .rc-fileformat which currently is only the job of the compiler. And to
>> my opinion it should stay the job of the compiler and shouldn't become
>> that of us using some unacceptably large NSIS script. Then as a second
>> point, the only information that might change on a regular basis is
>> currently (i.e. in SVN) already defined using command line definitions
>> (i.e. ${VERSION} and ${VERSIONNUM}) so there isn't a requirement for
>>
> Problem with those is that you can't create VERSIONNUM automatically out of
> VERSION. This might be suitable for the raw Makefiles, but certainly is not
> for the automake build...
> As a workaround I added a --with-installer-version switch to configure.
Well I suppose you could use an include file in the .rc-file which
contains the version numbers, which you would then parse with the above
mentioned GetBetween function. Then use those numbers as arguments
against VIAddVersionKey.
That should be easily implemented.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Warzone 2100 Review
Quote from: Piotr Szulczewski > I am a http://gamersunited.eu webmaster [...] > my e-mail is: piotr botul pl > My review of the newly modifyed WZ2100 is here: > http://gamersunited.topworld.org/warzone2.htm That review doesn't say anything about "the awesome Warzone 2100" or similar, but please be gentle to him when providing feedback! --Dennis pgpmqngYtW5Vm.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] warzone devpackage
Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 20:03 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: >>> Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > >> I assume that you've modified the warzone devpackage for that ( this >> one: http://download.gna.org/warzone/development/warzone-devpkg.7z ), >> would you care to upload the version you're using there? >> > Allready done, just didn't announce it yet. (MSVC package is not yet > uploaded.) > http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z > > The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. > Well that new MinGW devpackage doesn't work all to nice. It gives me a whole bunch of png related compiler errors. > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > -DWIN32 -c -opcx.o pcx.c > In file included from pcx.c:1: > C:/devpkg/include/png.h:1: error: expected constructor, destructor, or > type conversion before '/' token > C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' token > In file included from pcx.c:1: > C:/devpkg/include/png.h:1:15: warning: no newline at end of file > >>> Did you have a look at that png.h? >>> Could it be related to DOS/UNIX lineendings? >>> >> No, GCC (and as such MinGW) doesn't care about line-endings as long as >> they're the same throughout the file. >> >> When looking at that last error message you quoted it also indicates a >> line number of 1, which suggests the last line is nrl 1. Meaning there >> is only one line there, so I went to watch there and this where its >> contents exactly: "libpng12/png.h" (without quotes). >> While it should (most likely) be this: >> #include "libpng12/png.h" >> > The include/png.h in the devpkg you got only contains "libpng12/png.h" ??? > That's very odd, since mine is a full featured C header... > > >> So that's an easy fix, that fixes compiling. >> >> >> So now we're done compiling lets get trouble with linking. >> NOTE:all selected libraries are defined in makerules/config.mk (LDFLAGS) >> >> * -ljpeg6b cannot be found, I'm guessing -ljpeg should be used instead >> * -lpng13 cannot be found, if using -lpng instead it uses lib/libpng.a >> of which the linker says "lib/libpng.a: file format not recognized; >> treating as linker script" which of course fails miserably, so lets put >> my money on -lpng12 instead. >> > I think it should be -lpng, without any version number... > Well the linker doesn't recognize lib/libpng.a as a linklibrary so that doesn't help. I am instead using -lpng12 now, that does work. > There seems to be some Windows library missing. I guess those were pulled in > automatically by the DLLs or something... > Try adding -lwsock32 -lwinmm to the end... > While adding the *both* of those did help (i.e. they're both needed apparently) I'm now left with some libpng related errors. These however are fixed by appending a simple -lz to the linker list. So, provided that you modify the devpackage to have a correct include/png.h file (i.e. *with* #include directive in front of the file name that is to be included) wz should be compilable and linkable. The latter (linking) however requires the attached patch. Then for the purpose of actually running the executable it would be nice if you'd also include OpenAL32.dll and wrap_oal.dll into the devpackage. -- Giel Index: makerules/configure.mk === --- makerules/configure.mk (revision 576) +++ makerules/configure.mk (working copy) @@ -74,7 +74,7 @@ EXEEXT=.exe WINDRES=windres CFLAGS+=-mwindows -DWIN32 -LDFLAGS+=-lmingw32 -lglu32 -lopengl32 -lopenal32 -ljpeg6b -lpng13 +LDFLAGS+=-lmingw32 -lglu32 -lopengl32 -lopenal32 -ljpeg -lpng12 -lz else DIRSEP=/ RMF=rm -f @@ -85,4 +85,9 @@ LDFLAGS+=-lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net +# MS Winsock and winmm are still required by SDL on MSW +ifeq ($(strip $(PLATFORM)),windows) +LDFLAGS+=-lwsock32 -lwinmm +endif + include $(MAKERULES)/common.mk signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Warzone 2100 Review
On Wed, 27 Dec 2006 14:53:20 -0500 Dennis Schridde <[EMAIL PROTECTED]> wrote: >Quote from: Piotr Szulczewski >> I am a http://gamersunited.eu webmaster [...] >> my e-mail is: piotr botul pl >> My review of the newly modifyed WZ2100 is here: >> http://gamersunited.topworld.org/warzone2.htm >That review doesn't say anything about "the awesome Warzone 2100" >or similar, >but please be gentle to him when providing feedback! > > >--Dennis "The Campaign was very good in the original release but now, without the cutscenes removed brutaly by the Eidos Company, it's no fun anymore. The multiplayer on the other hand remained interresting." I wouldn't say it isn't fun, but it is missing that polish. I guess they also didn't have time to play multiplayer. :) " I'm looking forward to play the final GPL release!" Will there ever be a final release? I hope not. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Warzone 2100 Review
I guess you can only expect so much from a non-profit magazine. I sure hope that 2.1 will be so good that we can push it to paid-for magazines for inclusion on the accompanying CD, and perhaps even a review in the actual mag. That'd be awsome. :) 2006/12/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: On Wed, 27 Dec 2006 14:53:20 -0500 Dennis Schridde <[EMAIL PROTECTED]> wrote: >Quote from: Piotr Szulczewski >> I am a http://gamersunited.eu webmaster [...] >> my e-mail is: piotr botul pl >> My review of the newly modifyed WZ2100 is here: >> http://gamersunited.topworld.org/warzone2.htm >That review doesn't say anything about "the awesome Warzone 2100" >or similar, >but please be gentle to him when providing feedback! > > >--Dennis "The Campaign was very good in the original release but now, without the cutscenes removed brutaly by the Eidos Company, it's no fun anymore. The multiplayer on the other hand remained interresting." I wouldn't say it isn't fun, but it is missing that polish. I guess they also didn't have time to play multiplayer. :) " I'm looking forward to play the final GPL release!" Will there ever be a final release? I hope not. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev -- Venlig hilsen / Kind regards, Christian Vest Hansen. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] warzone devpackage
Am Mittwoch, 27. Dezember 2006 21:24 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 20:03 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> Am Mittwoch, 27. Dezember 2006 18:49 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 18:11 schrieb Giel van Schijndel: > >> I assume that you've modified the warzone devpackage for that ( this > >> one: http://download.gna.org/warzone/development/warzone-devpkg.7z > >> ), would you care to upload the version you're using there? > > > > Allready done, just didn't announce it yet. (MSVC package is not yet > > uploaded.) > > http://download.gna.org/warzone/development/warzone-devpkg-mingw32.7z > > > > The warzone-devpkg.7z will vanish when I uploaded the MSVC pkg. > > Well that new MinGW devpackage doesn't work all to nice. It gives me a > whole bunch of png related compiler errors. > > > g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. > > -IC:\devpkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows > > -DWIN32 -c -opcx.o pcx.c > > In file included from pcx.c:1: > > C:/devpkg/include/png.h:1: error: expected constructor, destructor, > > or type conversion before '/' token > > C:/devpkg/include/png.h:1: error: expected `,' or `;' before '/' > > token In file included from pcx.c:1: > > C:/devpkg/include/png.h:1:15: warning: no newline at end of file > >>> > >>> Did you have a look at that png.h? > >>> Could it be related to DOS/UNIX lineendings? > >> > >> No, GCC (and as such MinGW) doesn't care about line-endings as long as > >> they're the same throughout the file. > >> > >> When looking at that last error message you quoted it also indicates a > >> line number of 1, which suggests the last line is nrl 1. Meaning there > >> is only one line there, so I went to watch there and this where its > >> contents exactly: "libpng12/png.h" (without quotes). > >> While it should (most likely) be this: > >> #include "libpng12/png.h" > > > > The include/png.h in the devpkg you got only contains "libpng12/png.h" > > ??? That's very odd, since mine is a full featured C header... > > > >> So that's an easy fix, that fixes compiling. > >> > >> > >> So now we're done compiling lets get trouble with linking. > >> NOTE:all selected libraries are defined in makerules/config.mk (LDFLAGS) > >> > >> * -ljpeg6b cannot be found, I'm guessing -ljpeg should be used instead > >> * -lpng13 cannot be found, if using -lpng instead it uses lib/libpng.a > >> of which the linker says "lib/libpng.a: file format not recognized; > >> treating as linker script" which of course fails miserably, so lets put > >> my money on -lpng12 instead. > > > > I think it should be -lpng, without any version number... > > Well the linker doesn't recognize lib/libpng.a as a linklibrary so that > doesn't help. > I am instead using -lpng12 now, that does work. I found the issues: lrwxrwxrwx 1 sevendays users 10 2006-12-24 01:14 libpng.a -> libpng12.a lrwxrwxrwx 1 sevendays users14 2006-12-24 01:14 png.h -> libpng12/png.h I'll upload a corrected version of the devpkg... > > There seems to be some Windows library missing. I guess those were pulled > > in automatically by the DLLs or something... > > Try adding -lwsock32 -lwinmm to the end... > > While adding the *both* of those did help (i.e. they're both needed > apparently) I'm now left with some libpng related errors. > These however are fixed by appending a simple -lz to the linker list. > So, provided that you modify the devpackage to have a correct > include/png.h file (i.e. *with* #include directive in front of the file > name that is to be included) wz should be compilable and linkable. The > latter (linking) however requires the attached patch. > > Then for the purpose of actually running the executable it would be nice > if you'd also include OpenAL32.dll and wrap_oal.dll into the devpackage. > > -- > Giel pgpqDHQJ5CjLn.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Warzone 2100 Review
Am Mittwoch, 27. Dezember 2006 22:25 schrieb Christian Vest Hansen: > I guess you can only expect so much from a non-profit magazine. > > I sure hope that 2.1 will be so good that we can push it to paid-for > magazines for inclusion on the accompanying CD, and perhaps even a > review in the actual mag. > > That'd be awsome. :) That would really awesome. But a long way till then... --Dennis pgpJ7cC6GhC5j.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r577 - in /trunk: Makefile.am autogen.sh configure.ac makerules/config.mk.tmpl makerules/configure.mk nsis/Makefile.am nsis/Makefile.raw nsis/warzone2100.nsi win32/
Dennis Schridde schreef: > Author: devurandom > Date: Wed Dec 27 22:44:46 2006 > New Revision: 577 > > URL: http://svn.gna.org/viewcvs/warzone?rev=577&view=rev > Log: > NSIS support for automake. > raw Makefiles might be broken, please report back! Reporting back: Yes, the raw makefiles are broken now. Compiling is still possible, linking not anymore however. You removed -lmingw32 from the linker list, while this library is *always* required for the linking of stand-alone executables (i.e. no DLLs etc.) using MinGW. Furthermore -lSDL_net depends on -lwsock32 so -lwsock32 needs to be provided _later_ on the command line than -lSDL_net. The same seems to be the case with -lSDL and -lwinmm. The attached patch fixes these issues. -- Giel Index: makerules/configure.mk === --- makerules/configure.mk (revision 577) +++ makerules/configure.mk (working copy) @@ -74,7 +74,7 @@ EXEEXT=.exe WINDRES=windres CFLAGS+=-mwindows -DWIN32 -LDFLAGS+=-lwsock32 -lwinmm -lglu32 -lopengl32 -lopenal32 +LDFLAGS+=-lmingw32 -lglu32 -lopengl32 -lopenal32 else DIRSEP=/ RMF=rm -f @@ -85,4 +85,8 @@ LDFLAGS+=-ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net +ifeq ($(strip $(PLATFORM)),windows) +LDFLAGS+=-lwsock32 -lwinmm +endif + include $(MAKERULES)/common.mk signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Old website on gna.org
I just noticed (through a Google search) that the old web pages on home.gna.org/warzone are still online, without any notice of the new site. The above address redirects to wz.rootzilla.de, but the individual pages still exist, and when other pages link to them, there's no indication the page has been moved. -- I have also been a huge Unix fan ever since I realized that SCO was not Unix. -- Dennis Baker ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] C++ compatibility and codebase cleaning
Ok, I've decided I'm getting too awfully crazy from all the poorly written codebase in WZ. Therefore I have decided to start fixing lots of code. Firstly to be compilable without -fpermissive (to g++ that is). Then additionally I want to be able to compile it while using -Werror (causes all warnings to raise a error and stop compiling). As I've seen already this might require me to delete a lot of unused functions. I'll try to make sure that all modifications which delete functions are put in a separate patch from other kind of modifications. Then as a second point I noticed that some data types might: A) have to be redefined/modified; or B) require a huge amount of casting An example where casting might be valid (too my opinion that is): > const char* abc; > ... > strcpy((char*)abc,def); This might be valid *if* this call to strcpy is actually nothing more than initialization of the string *abc points to. For any other use than initialization however I'm guessing it is better to change the data type. So I've explained some details of how I'm going to achieve C++ compile-ability, if you have any tips/hints/advice/comments/whatever please tell me. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
On Wednesday, 27 December 2006 at 23:41, Giel van Schijndel wrote: > Ok, I've decided I'm getting too awfully crazy from all the poorly > written codebase in WZ. That's easy. > Therefore I have decided to start fixing lots of code. Firstly to be > compilable without -fpermissive (to g++ that is). That isn't - at least it seemed so to me the last time I looked. There are various types used like derived classes without being classes, so the compiler doesn't know and complains about incompatible types. Do you want to change all those to classes or how else did you want to fix that? > Then additionally I want to be able to compile it while using -Werror > (causes all warnings to raise a error and stop compiling). How about the other way round? First make the code compilable with -Werror (for both gcc and g++ -fpermissive) and then try without -fpermissive. > As I've seen already this might require me to delete a lot of unused > functions. I'll try to make sure that all modifications which delete > functions are put in a separate patch from other kind of modifications. I am all for removing unused stuff (be it functions, parameters or whatever), at least those that can't be easily reanimated. Most are just useless cruft. > Then as a second point I noticed that some data types might: > A) have to be redefined/modified; or As long as it keeps working... > B) require a huge amount of casting We already have that, we don't need even more of that. > An example where casting might be valid (too my opinion that is): > > const char* abc; > > ... > > strcpy((char*)abc,def); > This might be valid *if* this call to strcpy is actually nothing more > than initialization of the string *abc points to. For any other use than > initialization however I'm guessing it is better to change the data type. What about defining the string where it's initialized? Or is that incompatible with some compiler we care to support? > So I've explained some details of how I'm going to achieve C++ > compile-ability, if you have any tips/hints/advice/comments/whatever > please tell me. Your mail is lacking the _interesting_ details. :) I have once added a parameter to configure.ac (enable-gpp) that uses g++ instead of gcc and adjusts the CFLAGS accordingly, unfortunately I removed that tree without saving the diffs... If you're interested, I could hack up something like that again (perhaps not suitable for general inclusion, but then the whole autostuff is quite hackish...) -- There are two types of Linux developers - those who can spell, and those who can't. There is a constant pitched battle between the two. (From one of the post-1.1.54 kernel update messages posted to c.o.l.a) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
Christian Ohm schreef: > On Wednesday, 27 December 2006 at 23:41, Giel van Schijndel wrote: > >> Ok, I've decided I'm getting too awfully crazy from all the poorly >> written codebase in WZ. >> > That's easy. > >> Therefore I have decided to start fixing lots of code. Firstly to be >> compilable without -fpermissive (to g++ that is). >> > That isn't - at least it seemed so to me the last time I looked. There > are various types used like derived classes without being classes, so > the compiler doesn't know and complains about incompatible types. Do you > want to change all those to classes or how else did you want to fix > that? > >> Then additionally I want to be able to compile it while using -Werror >> (causes all warnings to raise a error and stop compiling). >> > How about the other way round? First make the code compilable with > -Werror (for both gcc and g++ -fpermissive) and then try without > -fpermissive. > I'm actually doing both at the same time: adding -Werror to CFLAGS and removing -fpermissive from it >> As I've seen already this might require me to delete a lot of unused >> functions. I'll try to make sure that all modifications which delete >> functions are put in a separate patch from other kind of modifications. >> > I am all for removing unused stuff (be it functions, parameters or > whatever), at least those that can't be easily reanimated. Most are just > useless cruft. > >> Then as a second point I noticed that some data types might: >> A) have to be redefined/modified; or >> > As long as it keeps working... > Obviously I intend to test these kind of modifications. >> B) require a huge amount of casting >> > We already have that, we don't need even more of that. > Agreed, I will therefore (except maybe for the example below) try to limit myself as much as possible in casting. >> An example where casting might be valid (too my opinion that is): >> >>> const char* abc; >>> ... >>> strcpy((char*)abc,def); >>> >> This might be valid *if* this call to strcpy is actually nothing more >> than initialization of the string *abc points to. For any other use than >> initialization however I'm guessing it is better to change the data type. >> > What about defining the string where it's initialized? Or is that > incompatible with some compiler we care to support? > Do you mean RAII ( http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization )? Well that is always good practice, the above example however refers to lib/framework/mem.c:173,180. Here an area of memory has just been malloc'ed and the requesting file is registered in the output struct as member `const char* ->pFile', then directly after mallocing the space for pFile it is assigned its value. And since this will (and/or *should*) be the only modification ever to occur to this string it is good to use `const' for this purpose. However strcpy expects `char*' for the destination string, so a cast seems fit here. >> So I've explained some details of how I'm going to achieve C++ >> compile-ability, if you have any tips/hints/advice/comments/whatever >> please tell me. >> > Your mail is lacking the _interesting_ details. :) > Just cleaning up stuff, this is just my initial tactic for the two most common errors I could find in 10 seconds (maybe a bit more, but you'll get the point). > I have once added a parameter to configure.ac (enable-gpp) that uses g++ > instead of gcc and adjusts the CFLAGS accordingly, unfortunately I > removed that tree without saving the diffs... If you're interested, I > could hack up something like that again (perhaps not suitable for > general inclusion, but then the whole autostuff is quite hackish...) > You mean simply compiling with g++ and add -Werror and remove -fpermissive from CFLAGS for g++? Because I'm already doing that using the raw makefile set (MinGW here). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
On Thursday, 28 December 2006 at 0:36, Giel van Schijndel wrote:
> Christian Ohm schreef:
> > How about the other way round? First make the code compilable with
> > -Werror (for both gcc and g++ -fpermissive) and then try without
> > -fpermissive.
> >
> I'm actually doing both at the same time: adding -Werror to CFLAGS and
> removing -fpermissive from it
Hm, ok, but if you first fix the code to compile with -Werror that could
be applied indepentently of making it compile with g++.
> >> An example where casting might be valid (too my opinion that is):
> >>
> >>> const char* abc;
> >>> ...
> >>> strcpy((char*)abc,def);
> >>>
> >> This might be valid *if* this call to strcpy is actually nothing more
> >> than initialization of the string *abc points to. For any other use than
> >> initialization however I'm guessing it is better to change the data type.
> >>
> > What about defining the string where it's initialized? Or is that
> > incompatible with some compiler we care to support?
> >
> Do you mean RAII (
> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization )?
I meant instead of
{
const char* abc;
...
strcpy((char*) abc, def);
}
using
{
...
const char* abc = def;
}
but your example was a bit more complicated. That looks like a candidate
for a constructor...
> Well that is always good practice, the above example however refers to
> lib/framework/mem.c:173,180.
> Here an area of memory has just been malloc'ed and the requesting file
> is registered in the output struct as member `const char* ->pFile', then
> directly after mallocing the space for pFile it is assigned its value.
> And since this will (and/or *should*) be the only modification ever to
> occur to this string it is good to use `const' for this purpose. However
> strcpy expects `char*' for the destination string, so a cast seems fit here.
> > I have once added a parameter to configure.ac (enable-gpp) that uses g++
> > instead of gcc and adjusts the CFLAGS accordingly, unfortunately I
> > removed that tree without saving the diffs... If you're interested, I
> > could hack up something like that again (perhaps not suitable for
> > general inclusion, but then the whole autostuff is quite hackish...)
> >
> You mean simply compiling with g++ and add -Werror and remove
> -fpermissive from CFLAGS for g++?
I was adding -fpermissive to the CFLAGS, and removing some -Ws g++
doesn't support.
> Because I'm already doing that using the raw makefile set (MinGW here).
Ok, then you won't need my autoconf hacks.
--
"Oh dear, I think you'll find reality's on the blink again."
-- Marvin The Paranoid Android
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
Christian Ohm schreef:
> On Thursday, 28 December 2006 at 0:36, Giel van Schijndel wrote:
>
>> Christian Ohm schreef:
>>
>>> How about the other way round? First make the code compilable with
>>> -Werror (for both gcc and g++ -fpermissive) and then try without
>>> -fpermissive.
>>>
>> I'm actually doing both at the same time: adding -Werror to CFLAGS and
>> removing -fpermissive from it
>>
> Hm, ok, but if you first fix the code to compile with -Werror that could
> be applied indepentently of making it compile with g++.
>
Sorry, but could you tell me what value that adds? (For, I haven't got a
clue, since I'm not breaking plain C support this way).
An example where casting might be valid (too my opinion that is):
> const char* abc;
> ...
> strcpy((char*)abc,def);
>
This might be valid *if* this call to strcpy is actually nothing more
than initialization of the string *abc points to. For any other use than
initialization however I'm guessing it is better to change the data type.
>>> What about defining the string where it's initialized? Or is that
>>> incompatible with some compiler we care to support?
>>>
>> Do you mean RAII (
>> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization )?
>>
> I meant instead of
>
> {
> const char* abc;
>
> ...
>
> strcpy((char*) abc, def);
> }
>
> using
>
> {
> ...
>
> const char* abc = def;
> }
>
> but your example was a bit more complicated. That looks like a candidate
> for a constructor...
Indeed I thought of that right away as a matter of fact. The only
problem in this case is that constructors are a feature provided by
classes, and I don't feel like modifying every single piece of code that
uses MALLOC (yes uppercase it's a macro defined in lib/framework/mem.h).
Just for the sake of cleaning up a piece of code which is nothing more
than a malloc wrapper which is a function you never, ever should use in
pure C++. So in this particular case I think it's best to simply remove
all dependencies to this function (using C++ classes and constructors
instead).
So I'll stay with a simple fix to make it compile with specified command
line options to g++.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Lua-WRF
Hello everyone! I can't find the last thread on this topic anymore, so I started a new one... I am currently into replacing the resource system with a Lua driven one. Works well so far. (Am only in the very early stages.) The concerns some of you had, that Lua could be too slow for that task, are very very probably wrong. I just tried to parse 20k modules. (Each mod had only 2 resources, but when I look at the current code: 20k mods with only 2 resources is very probably worse than 1k mods with 20 resources each. And even having 1k mods is highly unrealistic.) It seems like the place where it needs the most time is the dependency creation part, which currently only consists of some nested for loops walking the whole mod and resource list to find the deps. If I exchange the string compares against some hashing and use a tree instead of a list, I guess it will be fast enough. --Dennis pgpGm7zG09DKy.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r577 - in /trunk: Makefile.am autogen.sh configure.ac makerules/config.mk.tmpl makerules/configure.mk nsis/Makefile.am nsis/Makefile.raw nsis/warzone2100.nsi wi
Am Mittwoch, 27. Dezember 2006 23:22 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Author: devurandom > > Date: Wed Dec 27 22:44:46 2006 > > New Revision: 577 > > > > URL: http://svn.gna.org/viewcvs/warzone?rev=577&view=rev > > Log: > > NSIS support for automake. > > raw Makefiles might be broken, please report back! > > Reporting back: > > Yes, the raw makefiles are broken now. > Compiling is still possible, linking not anymore however. > > You removed -lmingw32 from the linker list, while this library is > *always* required for the linking of stand-alone executables (i.e. no > DLLs etc.) using MinGW. > Furthermore -lSDL_net depends on -lwsock32 so -lwsock32 needs to be > provided _later_ on the command line than -lSDL_net. The same seems to > be the case with -lSDL and -lwinmm. > > The attached patch fixes these issues. Swaping the if(windows) part with the generic one is not possible I guess? Would remove the need for yet another if... --Dennis pgpbyeniiWvFB.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r577 - in /trunk: Makefile.am autogen.sh configure.ac makerules/config.mk.tmpl makerules/configure.mk nsis/Makefile.am nsis/Makefile.raw nsis/warzone2100.nsi wi
Dennis Schridde schreef: > Am Mittwoch, 27. Dezember 2006 23:22 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> Author: devurandom >>> Date: Wed Dec 27 22:44:46 2006 >>> New Revision: 577 >>> >>> URL: http://svn.gna.org/viewcvs/warzone?rev=577&view=rev >>> Log: >>> NSIS support for automake. >>> raw Makefiles might be broken, please report back! >>> >> Reporting back: >> >> Yes, the raw makefiles are broken now. >> Compiling is still possible, linking not anymore however. >> >> You removed -lmingw32 from the linker list, while this library is >> *always* required for the linking of stand-alone executables (i.e. no >> DLLs etc.) using MinGW. >> Furthermore -lSDL_net depends on -lwsock32 so -lwsock32 needs to be >> provided _later_ on the command line than -lSDL_net. The same seems to >> be the case with -lSDL and -lwinmm. >> >> The attached patch fixes these issues. >> > Swaping the if(windows) part with the generic one is not possible I guess? > Would remove the need for yet another if... No, the linker order is imperative here. You could put the unconditional LDFLAGS in something like GLOBAL_LDFLAGS and then refer to $(GLOBAL_LDFLAGS) within the first if(windows) section. That choice I will however leave up to you (hehe :-P ) -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Old website on gna.org
Am Mittwoch, 27. Dezember 2006 23:32 schrieb Christian Ohm: > I just noticed (through a Google search) that the old web pages on > home.gna.org/warzone are still online, without any notice of the new > site. The above address redirects to wz.rootzilla.de, but the individual > pages still exist, and when other pages link to them, there's no > indication the page has been moved. Should be solved in a few minutes, when the Gna cronjob updated the site. (I deleted everything but index.html) --Dennis pgpDAO1LP8ZX7.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
Am Mittwoch, 27. Dezember 2006 23:41 schrieb Giel van Schijndel: > Ok, I've decided I'm getting too awfully crazy from all the poorly > written codebase in WZ. > > Therefore I have decided to start fixing lots of code. Firstly to be > compilable without -fpermissive (to g++ that is). Then additionally I > want to be able to compile it while using -Werror (causes all warnings > to raise a error and stop compiling). > > As I've seen already this might require me to delete a lot of unused > functions. I'll try to make sure that all modifications which delete > functions are put in a separate patch from other kind of modifications. > > Then as a second point I noticed that some data types might: > A) have to be redefined/modified; or > B) require a huge amount of casting > > An example where casting might be valid (too my opinion that is): > > const char* abc; > > ... > > strcpy((char*)abc,def); > > This might be valid *if* this call to strcpy is actually nothing more > than initialization of the string *abc points to. For any other use than > initialization however I'm guessing it is better to change the data type. > > So I've explained some details of how I'm going to achieve C++ > compile-ability, if you have any tips/hints/advice/comments/whatever > please tell me. Looks ok so far. Just, as Christian allready said: Limit casting to a minimum. Casting is bad, especially in C. ;) Changing the types of the variables is much better and in most cases possible somehow. Those char* thingies are also present a lot in the scripting part, eg in the structs used in scripttabs.c. I once tried to change that to const char*, but I think there was an issue or something. I think Stefan had some probably better patch, but he didn't yet show it I fear. --Dennis pgpCAFlrfZt7z.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r577 - in /trunk: Makefile.am autogen.sh configure.ac makerules/config.mk.tmpl makerules/configure.mk nsis/Makefile.am nsis/Makefile.raw nsis/warzone2100.nsi
Am Donnerstag, 28. Dezember 2006 01:42 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Mittwoch, 27. Dezember 2006 23:22 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: > >>> Author: devurandom > >>> Date: Wed Dec 27 22:44:46 2006 > >>> New Revision: 577 > >>> > >>> URL: http://svn.gna.org/viewcvs/warzone?rev=577&view=rev > >>> Log: > >>> NSIS support for automake. > >>> raw Makefiles might be broken, please report back! > >> > >> Reporting back: > >> > >> Yes, the raw makefiles are broken now. > >> Compiling is still possible, linking not anymore however. > >> > >> You removed -lmingw32 from the linker list, while this library is > >> *always* required for the linking of stand-alone executables (i.e. no > >> DLLs etc.) using MinGW. > >> Furthermore -lSDL_net depends on -lwsock32 so -lwsock32 needs to be > >> provided _later_ on the command line than -lSDL_net. The same seems to > >> be the case with -lSDL and -lwinmm. > >> > >> The attached patch fixes these issues. > > > > Swaping the if(windows) part with the generic one is not possible I > > guess? Would remove the need for yet another if... > > No, the linker order is imperative here. Is that because of the Windows libs? A line like -ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net -lGLU -lGL -lopenal works here (Linux/Makefile.raw) On Windows it would look like -ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net -lmingw32 -lwsock32 -lwinmm -lglu32 -lopengl32 -lopenal32 That way the wsock and winmm stuff would still be linked before SDL... --Dennis pgpEdb1k6zZLN.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] C++ compatibility and codebase cleaning
On Thursday, 28 December 2006 at 1:28, Giel van Schijndel wrote:
> Christian Ohm schreef:
> > Hm, ok, but if you first fix the code to compile with -Werror that could
> > be applied indepentently of making it compile with g++.
> >
> Sorry, but could you tell me what value that adds? (For, I haven't got a
> clue, since I'm not breaking plain C support this way).
Fixing warnings and making the code g++ compatible are two separate
things; the warning fixes could be applied first, so the whole code
compiles with -Werror. Then you can fix the errors cropping up when
removing -fpermissive.
> > I meant instead of
> >
> > {
> > const char* abc;
> >
> > ...
> >
> > strcpy((char*) abc, def);
> > }
> >
> > using
> >
> > {
> > ...
> >
> > const char* abc = def;
> > }
> >
> > but your example was a bit more complicated. That looks like a candidate
> > for a constructor...
> Indeed I thought of that right away as a matter of fact. The only
> problem in this case is that constructors are a feature provided by
> classes, and I don't feel like modifying every single piece of code that
> uses MALLOC (yes uppercase it's a macro defined in lib/framework/mem.h).
> Just for the sake of cleaning up a piece of code which is nothing more
> than a malloc wrapper which is a function you never, ever should use in
> pure C++. So in this particular case I think it's best to simply remove
> all dependencies to this function (using C++ classes and constructors
> instead).
Yeah, in that case the cast is acceptable. I wasn't really looking at
the code, just enough to see what you mean.
--
I love Mickey Mouse more than any woman I've ever known.
-- Walt Disney
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r577 - in /trunk: Makefile.am autogen.sh configure.ac makerules/config.mk.tmpl makerules/configure.mk nsis/Makefile.am nsis/Makefile.raw nsis/warzone2100.nsi wi
Dennis Schridde schreef: > Am Donnerstag, 28. Dezember 2006 01:42 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> Am Mittwoch, 27. Dezember 2006 23:22 schrieb Giel van Schijndel: >>> Dennis Schridde schreef: > Author: devurandom > Date: Wed Dec 27 22:44:46 2006 > New Revision: 577 > > URL: http://svn.gna.org/viewcvs/warzone?rev=577&view=rev > Log: > NSIS support for automake. > raw Makefiles might be broken, please report back! > Reporting back: Yes, the raw makefiles are broken now. Compiling is still possible, linking not anymore however. You removed -lmingw32 from the linker list, while this library is *always* required for the linking of stand-alone executables (i.e. no DLLs etc.) using MinGW. Furthermore -lSDL_net depends on -lwsock32 so -lwsock32 needs to be provided _later_ on the command line than -lSDL_net. The same seems to be the case with -lSDL and -lwinmm. The attached patch fixes these issues. >>> Swaping the if(windows) part with the generic one is not possible I >>> guess? Would remove the need for yet another if... >>> >> No, the linker order is imperative here. >> > Is that because of the Windows libs? > Yes, it is. > A line like > -ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL > -lSDL_net -lGLU -lGL -lopenal > works here (Linux/Makefile.raw) > > On Windows it would look like > -ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL > -lSDL_net -lmingw32 -lwsock32 -lwinmm -lglu32 -lopengl32 -lopenal32 > > That way the wsock and winmm stuff would still be linked before SDL... > Actually ^^ that way (the windows command line you've provided) causes wsock and winmm to be linked *after* SDL, which is exactly how it should be. Currently, however, it looks like this on windows: > -lwsock32 -lwinmm -lglu32 -lopengl32 -lopenal32 -ljpeg -lpng -lz -lmad > -lvorbisfile -lvorbis -logg -lphysfs -lSDLmain -lSDL -lSDL_net So to acquire the line you've got you'd have to swap the global and the if(windows) section. This however would still require another if(windows) section (before the global one) since -lmingw32 needs to be the first lib specified, otherwise linking will fail with unsatisfied references to '[EMAIL PROTECTED]'. So as long as you make sure that the output set of libs is in this order it should link: > -lmingw32 -ljpeg -lpng -lz -lmad -lvorbisfile -lvorbis -logg -lphysfs > -lSDLmain -lSDL -lSDL_net -lwsock32 -lwinmm -lglu32 -lopengl32 -lopenal32 -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
