[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:

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

[dizzy]

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).

[Kazan]

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

[dizzy]

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

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!

[dizzy]

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:

Code: [Select]


#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:

Code: [Select]


#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 ?

[dizzy]

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 ?

[dizzy]

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!

[Kazan]

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

[dizzy]

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 ?

[dizzy]

Updated strnicmp implementation with this one:

Code: [Select]


#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++).

[WMCoolmon]

#ifndef WIN32
#define strnicmp strncasecmp
#define stricmp strcasecmp
#endif

[dizzy]

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:

Code: [Select]


#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 */


[dizzy]

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

[Kazan]

what version of wxWidgets and DevIL are you using?


register an sf.net account and i'll give you write access to the repository

[dizzy]

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):


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!

[Kazan]

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

[dizzy]

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

[Kazan]

ok i just tried using your autotool files and got

Code: [Select]


[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



[dizzy]

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"

[Kazan]

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)