Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: dizzy on September 01, 2005, 10:46:10 am
-
Hello
(man, I HATE anonymous sf.net CVS, it's so fscking slow!! :))
I started to trying to add autotools support for VPCS. However there are the following problems:
1. somehow in CVS VPHeader.h is actually VPheader.h as such, if you checkout CVS on a filesystem that is case sensitive (like reiserfs back here) you won't get this compiled because it won't find VPHeader.h to include it. I temporarly changed #include from VPheader.h to VPheader.h to get it going but you (Kazan) probably should do some solution in CVS too :)
2. you seem to be using the old, deprecated, pre-ANSI SQL98 header files (like iostream.h and such instead of "iostream"); this generates a lot of warnings from g++ (yeah, it can be made silent about what with -Wno-deprecated); let's not start another flame on ANSI SQL98 here, common is not like you have some huge project there (vpcs seems to me like a very small project) so it's about chaning very few lines and also we are not talking about a standard adopted yesterday, we talk about C++98, like 7 years ago, duh
3. some minor warnings about no end of line at the end of file:
vpcs2.h:270:19: warning: no newline at end of file
dialogs.h:96:26: warning: no newline at end of file
4. I am unable to get it compiled; I had no time to really try to fix it but to me it really shows like a code bug, is the current CVS compiling for you ? :)
if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"wxAuto\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -Wno-deprecated -I/usr/lib64/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -g -O2 -I/usr/lib64/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -MT vpcs2.o -MD -MP -MF ".deps/vpcs2.Tpo" -c -o vpcs2.o vpcs2.cpp; \
then mv -f ".deps/vpcs2.Tpo" ".deps/vpcs2.Po"; else rm -f ".deps/vpcs2.Tpo"; exit 1; fi
vpcs2.cpp: In constructor `VPCS2_MainWindow::VPCS2_MainWindow()':
vpcs2.cpp:114: error: no matching function for call to `VPCS2_MainPanel::VPCS2_MainPanel(VPCS2_MainWindow* const, wxSize, wxStatusBar*&)'
vpcs2.h:141: note: candidates are: VPCS2_MainPanel::VPCS2_MainPanel(const VPCS2_MainPanel&)
vpcs2.h:167: note: VPCS2_MainPanel::VPCS2_MainPanel(wxFrame*, wxSize&, wxStatusBar*)
vpcs2.cpp: In member function `void VPCS2_MainWindow::Del_Dir(wxEvent&)':
vpcs2.cpp:264: error: no matching function for call to `VPCS2_MainPanel::DeleteDirectory(wxTreeItemId)'
vpcs2.h:208: note: candidates are: void VPCS2_MainPanel::DeleteDirectory(wxTreeItemId&)
Thanks for any help!
PS: btw, is PCS2 completely dead or should I try to get that too on autotools ? Seems Taylor has a nice working Makefile but with autotools I can make it automatically detect where is wxWidgets installed (also a configure --option in special cases) and so on.
Edit log: initially I noticed that the pasted error above get's translated at some points into smileys so I said I should wrap it with code tags but that didn't helped for the smileys either, isntead it was worse that it didnt automatically brake the lines anymore and you got a very long post (long lines post); so I removed the "code" tags back :)
-
One more thing, if you feel into testing this, please get http://dizzy.roedu.net/fs/vpcs2-autotools.tar.gz . Unpack it so that you have autogen.sh, configure.ac and Makefile.am in a directory with the vpcs files. Run autogen.sh to generate the rest of the needed build files. Then the usual way, configure, make, make install (you shouldn't get here because of those compile errors).
-
right now I'm working on POF Constructor Suite 2.x
These VPCS 2.x issues will get resolved later
Originally posted by dizzy
Hello
(man, I HATE anonymous sf.net CVS, it's so fscking slow!! :))
I started to trying to add autotools support for VPCS. However there are the following problems:
Originally posted by dizzy
1. somehow in CVS VPHeader.h is actually VPheader.h as such
i'll get this cleaned up -
Originally posted by dizzy
2. you seem to be using the old, deprecated, pre-ANSI SQL98
this is from some of my older libs that got upgraded
the insult was not required.
Originally posted by dizzy
3. some minor warnings about no end of line at the end of file:
vpcs2.h:270:19: warning: no newline at end of file
dialogs.h:96:26: warning: no newline at end of file
these will get fixed
Originally posted by dizzy
4. I am unable to get it compiled; I had no time to really try to fix it but to me it really shows like a code bug, is the current CVS compiling for you ? :)
if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"wxAuto\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -Wno-deprecated -I/usr/lib64/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -g -O2 -I/usr/lib64/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -MT vpcs2.o -MD -MP -MF ".deps/vpcs2.Tpo" -c -o vpcs2.o vpcs2.cpp; \
then mv -f ".deps/vpcs2.Tpo" ".deps/vpcs2.Po"; else rm -f ".deps/vpcs2.Tpo"; exit 1; fi
vpcs2.cpp: In constructor `VPCS2_MainWindow::VPCS2_MainWindow()':
vpcs2.cpp:114: error: no matching function for call to `VPCS2_MainPanel::VPCS2_MainPanel(VPCS2_MainWindow* const, wxSize, wxStatusBar*&)'
vpcs2.h:141: note: candidates are: VPCS2_MainPanel::VPCS2_MainPanel(const VPCS2_MainPanel&)
vpcs2.h:167: note: VPCS2_MainPanel::VPCS2_MainPanel(wxFrame*, wxSize&, wxStatusBar*)
vpcs2.cpp: In member function `void VPCS2_MainWindow::Del_Dir(wxEvent&)':
vpcs2.cpp:264: error: no matching function for call to `VPCS2_MainPanel::DeleteDirectory(wxTreeItemId)'
vpcs2.h:208: note: candidates are: void VPCS2_MainPanel::DeleteDirectory(wxTreeItemId&)
cast "this" to "(wxFrame*)this" and it should compile
Thanks for any help!
PS: btw, is PCS2 completely dead or should I try to get that too on autotools ?
PCS2 is still in alpha - there is a huge dev thread in FreeSpace Modding
Seems Taylor has a nice working Makefile but with autotools I can make it automatically detect where is wxWidgets installed (also a configure --option in special cases) and so on.
that would be nice and thanks :D
-
Originally posted by Kazan
right now I'm working on POF Constructor Suite 2.x
These VPCS 2.x issues will get resolved later
Ok, just bump this thread when you feel I should start on this again :)
this is from some of my older libs that got upgraded
the insult was not required.
If I insulted you please accept my apologies. I had absolutely no such intention. I was wrong to believe (from the other thread) that you had some general issues with the C++ standard and I just didn't felt like arguing why a 7 years old standard shouldn't be avoided on reasons that "it brakes compatibility with older codes" (yes, you probably have not said such a thing at all, sorry for the confusion). Please believe me :)
PCS2 is still in alpha - there is a huge dev thread in FreeSpace Modding
Ok, going to look at it, thanks!
that would be nice and thanks :D
You are welcome. I am just trying now by doing various "cleaning jobs" to get a hold of the codes and of the community itself as this project is more than just a set of codes but a community of people working, joking, arguing and learning. Up until now at least, this community is great! Keep up the good work!
-
Hi again
I started to look into adding autotools for PCS2. It's a lot more complex than VPCS (obviously) :). Ok, I have the autotools files which seem to work fine. The only issues remaining to be solved are a lot of code incompatibities which we need to clear them up before getting it to compile on Linux for example.
I will make different posts because they are different problems and pretty long too.
First I have a question for a decision to make. That is how do we add portability to specific unportable functions. For example there is the strnicmp() function. There are systems which have the equivalent of strncasecmp() but because it is neither of this functions are covered by any standard there are a LOT of systems that don't have any. As such I have created a .h/.cpp file pair to implement a portable strnicmp(). The .h file is as this:
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif
#ifdef HAVE_STRING_H
# include <string.h>
#endif
#ifndef HAVE_STRNICMP
#ifdef HAVE_STRNCASECMP /* maybe we have the other popular name for it */
#define strnicmp(s1,s2,len) strncasecmp(s1,s2,len)
#else /* no option, use our own implementation of it */
int strnicmp(const char* s1, const char* s2, int len);
#endif /* HAVE_STRNCASECMP */
#endif /* !HAVE_STRNICMP */
#endif /* STRNICMP_INCLUDED */
Obviously the strnicmp.c file contains a simple "let's do it" implementation of the function in case neither strnicmp() or strncasecmp() exists on the system, that is:
#include "strnicmp.h"
#ifndef HAVE_STRNICMP
#ifndef HAVE_STRNCASECMP
int strnicmp(const char* s1, const char* s2, int len)
{
for(;*s1;s1++, s2++) {
if (*s1 < *s2) return -1;
else if (*s1 > *s2) return 1;
}
return 0;
}
#endif
#endif
You might ask what's all about with the ifdef HAVE_CONFIG_H include <config.h> parts. With autoconf system for detecting system dependant features (libs, functions, headers) after the detection script runs it creates a .h file called config.h that includes stuff like
#define HAVE_STRNCASECMP 1
(in case strncasecmp() was detected on the system). This allows to have a program to ifdef after that and enable/disable features based on that. But this also means, that with this aproach, the sources that you use on Win32 compilation need to have some config.h file (that you manually edit to enable/disable the features in it). Do you have other sugestion for this problem ?
-
Second issue/problem. There are includes for OGL like this:
#include <gl/gl.h>
On my system (and AFAIK on most Unix systems) it is actually <GL/gl.h>. Because of filesystem case sensitivity this is a problem. Now one might say to add detection of the system existent gl.h path to autoconf. Unfortunetly I dont think it is possible for autoconf to differentiate between gl/gl.h and GL/gl.h because as you have seen from the previous post the #defines it makes are all upper cased as such you cannot make a difference between HAVE_GL_GL_H and HAVE_GL_GL_H :)
I thought that just by changing all #include <gl/gl.h> to <GL/gl.h< whould be a nice workarround because it shouldnt brake Win32 because Win32 is not case sensitive on path names :) What do you think ?
-
And the last issues are:
- what is ilu/ilu.h & co and from what package I should get them ? :)
- also please take a look at the modifications I have done so far, some of them are really required because it seems that VC++ is just too permisive with some things (like allows chaining of overloaded "+" operator usage when the overloaded operator is not defined to get as input const references but "read/write" references, this totally fails with g++); so please look at http://dizzy.roedu.net/fs/pcs2-compat1.patch
Thanks!
-
your implementation of strnicmp is incorrect - the i in the name indicates case-insensitivity
IL.h, ILU.h and ILUT.h are from DevIL - openil.sourceforge.net
-
Correct, forgot about the case (AND the size limitation, damn, I was really in a hurry with this it seems) :). What do you think about the rest ?
-
Updated strnicmp implementation with this one:
#include <ctype.h>
#include "strnicmp.h"
#ifndef HAVE_STRNICMP
#ifndef HAVE_STRNCASECMP
int strnicmp(const char* s1, const char* s2, int len)
{
for(;*s1 && len > 0;s1++, s2++, len--) {
const char c1 = tolower(*s1);
const char c2 = tolower(*s2);
if (c1 < c2) return -1;
else if (c1 > c2) return 1;
}
return 0;
}
#endif
#endif
I have benchmarked this version (with the temrporary c1/c2 variables) against a version that was calling tolower() on *s1/*s2 where we compared them and this version is at least 3 times faster than the one repeating tolower() calls (at least on g++).
-
#ifndef WIN32
#define strnicmp strncasecmp
#define stricmp strcasecmp
#endif
-
That's not so good. Therea are 2 problems with it
1. It presumes that the local system REALLY DOES have strncasecmp in case it is non-Win32, that as too BIG assumtion to make considering we are speaking of fairly exotic functions here, not covered by any standard and not something historically used. I dont have right now a *BSD to test out (can be arranged quickly tho) but I would be pretty sure that they miss those functions, not to mention Solaris or Mac OS X. As such, autoconf always has to check which one does the system has (strnicmp, or strncasecmp or none) and use the one accordingly.
2. WIN32 probably is also defined when compiling with Borland C++ compiler, does this compiler has strnicmp() ? But I guess you wouldnt want to support Borland C++ anyways, so we can go for the moment with the assumtion if WIN32 is defined then we surely have strnicmp() (this does not affect in any way what I said at point 1 :))
You are right about doing a similar thing for strncmp() just to be sure (althought it is covered by POSIX.1 and ANSI C99).
So, strnicmp.h becomes strncmp.h with the contents:
#ifndef STRNICMP_INCLUDED
#define STRNICMP_INCLUDED
/* offer a portable layer for strnicmp() */
#ifdef WIN32
/* presume that WIN32 defined means always have strncmp() and strnicmp()
* declared into string.h (FIXME: is this always true ?) */
# include <string.h>
#else
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif
#ifdef HAVE_STRING_H
# include <string.h>
#endif
#ifndef HAVE_STRNCMP
int strncmp(const char* s1, const char* s2, int len);
#endif /* HAVE_STRNCMP */
#ifndef HAVE_STRNICMP
#ifdef HAVE_STRNCASECMP /* maybe we have the other popular name for it */
#define strnicmp(s1,s2,len) strncasecmp(s1,s2,len)
#else /* no option, use our own implementation of it */
int strnicmp(const char* s1, const char* s2, int len);
#endif /* HAVE_STRNCASECMP */
#endif /* !HAVE_STRNICMP */
#endif /* WIN32 */
#endif /* STRNICMP_INCLUDED */
-
I have updated the tarball at http://dizzy.roedu.net/fs/pcs2-0.0.1.tar.gz . Now compiles fine :)
But, crashes on startup (segmentation fault). Probably might have to do with me running on 64bit, we will see :)
-
what version of wxWidgets and DevIL are you using?
register an sf.net account and i'll give you write access to the repository
-
I am using wxWidgets 2.6.1 (didn't compiled with my system default 2.4.x one so I had to upgrade, the autoconf project also checks for a minimum 2.6.0 wxWidgets present) and Devil 1.6.7.
I have managed to find out why it crashes. It seems that my system doesn't like WX_GL_DEPTH_SIZE attribute set to 32. "glxinfo" command on my system shows all modes with depth of "24". If I change attribute list in PCS2_MainPanel.c::InitControls() to "24" then it gets rolling :) Any idea ?
Btw, I have updated the codes at the same URL. It now compiles AND starts up fine on my linux system :) Here is a screenshot (yes the list from the left shows strange):
(http://dizzy.roedu.net/fs/pcs2.png)
Thanks for the CVS offer. My sf.net account is "memeics". I would like tho to still have your consueling before commiting at least for a while because I don't want to screw up using a total different coding style or anything like that :) But at least adding me to CVS whould allow me be more productive as sf.net anon CVS is soooooo slow. Thanks! :)
-
I'm compiling against 2.6.1 on windows
24-bit depth is fine - openGL has to be the same bpp as your desktop depth in X if you request 24 you may get "24 or better" and the linux implementation tends to max out at 24 depth bits on most drivers
you now have write access
-
Thanks!
I am very busy right now (as you might have noticed by the lack of any activity here) learning for my exams (theory of informatics, algebra theory and so on...). Is there any other communication device (except these forums) that you coders use ? i mean something more interactive, like to some questions maybe are not that important to be said in here :)
-
ok i just tried using your autotool files and got
[kazan@kazanmobile pcs2]$ ./autogen.sh
aclocal:configure.ac:13: warning: macro `AM_OPTIONS_WXCONFIG' not found in library
aclocal:configure.ac:14: warning: macro `AM_PATH_WXCONFIG' not found in library
-
I see. I do not know 100% sure why you get them but I presume is because maybe your wxwindows installation didnt installed local macros for automake. For example my wxGTK package also installs:
/usr/share/aclocal/wxwin.m4
Which contains the AM_OPTIONS_WXCONFIG and AM_PATH_WXCONFIG m4 macros used when running "aclocal" (from withing autogen.sh) to build aclocal.m4 in the current directory. This macros are the proper way to check for the library (wxWindows provides them themselves as such instead of doing our own we should use theirs). However, the tarball I made with "make dist" named pcs2-0.0.1.tar.gz also contains aclocal.m4 (and everything else generated by "autogen.sh") so you don't need to run autogen.sh. Just "configure", "make" , "make install" :)
-
my install is different then yours so i do have to rerun them -especially since i've added sourcefiles since you've last altered Makefile.in
what of those files need to be cvs-i-fied (by the filelength() function will be going kersplat because i was going to code it out entirely)
-
Only Makefile.am's files (the one from basedir and the one from "compat" if you intend to include that too), configure.ac and autogen.sh to make regeneration fast. However, I can help out updating them if you are doing the compat stuff differently.
-
(http://www.ferrium.org/media/pcs2_linux.png)
-
Hey, now that's cool! :) Anyways, you seem to have managed to get it working fine, here it crashed when trying to load some pof file (might be I was loading a bad pof or that I use Linux/AMD64). Or maybe you have made some other changes too to the codes :)
-
And how about getting it in CVS so that we can all play!! :D
-
i cvs committed everything but the autotools
i am having to **** with the configure.ac because i'm having problems with the detection of DevIL
-
If I remember well, to detect the three DevIL libraries I just check for their init functions in each of them. The check tries to compile a program by declaring that function and linking it to the libs (AC_CHECK_LIB) to see if it links and if it does it should add it to LIBS variable replaced into Makefile.in's. What's the problem, maybe we can help :)
-
false negatives
-
I can make configure.ac bail out on negatives (it should anyways if you think of it, you require DevIL to be present) and then it should be easy to check it out what exactly fails in config.log.
Basically if your lib is installed in a directory listed in /etc/ld.so.conf (like /usr/lib, /usr/local/lib, etc) then try to rerun "ldconfig" to rebuild the ld.so.cache if you have installed DevIL recently. If you installed DevIL libs into another, exotic directory "export LD_LIBRARY_PATH" variable to point to that place before running configure... But in any case, checking out "config.log" should show exactly what fails on the test program that configure tries to compile and link to test for the library presence.
-
if was failing out on negatives - it was falsely reporting negatives - simply hacking the finished makefile and adding -lIL -lILU -lILUT links and /etc/ld.so.conf is configured recorrect.
and thanks for the info on config.log - i'll restore the origional macros and check
and WTFH is with strcpy() not working? i had to replace all calls to strcpy() with strncpy()!
i have other bugs of this unexplained nature that i've never encountered on linux before
-
Oh, I have no idea with strcpy(). I don't remember touching anything about strcpy(), only strncmp()/strncasecmp(). You get errors when compiling about strcpy() ? Or when linking ?
I didnt got any errors about that, very strange :)
But by rereading your message my guess is that you are speaking of runtime behaivour bugs, strange. Make sure you are not using strcpy() when source and destination overlap (is the equivalent of memcpy() with the same limitations). If they do overlap you whould have to use memmove() instead (of course, with length precalculation). For debugging memory problems under Linux I also recommend valgrind, www.valgrind.org. Is an easy to install/use memory debugging tool that acts like a CPU emulator, it catches all read/write operations and at the library level (all new/delete operations) and so on. If for example you have problems like using strcpy() on overlapping strings he will tell you so :) (that's how I found out about such a "strange" bug I was having with strcpy() some time ago...). Or maybe you should consider using std::string instead of C-strings and their operations if you are not time critical :)
After installing valgrind just use something like this to start your program:
$ valgrind --tool=memcheck --num-callers=10 ./pcs2
"valgrind" might not be very useful if you get hundred of errors from it (not because it might be a valgrind bug but still it's not useful when that happens).
-
run time errors - it simply would not perform it's function
src and dst do not overlap - i was using strcpy inside my custom C++ string class (cannot debug into std::string and std::vector on windows.. gives you garbage)