On Sun, 3 Jul 2005, Jean Bréfort wrote: > Hi, > > I found other build issues: > > In file included from ./filetrans.h:16, > from ./filetrans.cpp:10: > ./appconfig.h:63:1: warning: "PACKAGE_NAME" redefined > In file included from ./filetrans.h:13, > from ./filetrans.cpp:10: > /usr/local/include/ghemical/libconfig.h:71:1: warning: this is the > location of the previous definition > > I think that including a *config.h file in headers is generally a very > bad idea and should be done only if absolutely necessary. If necessary > (seems it is the case for some files), it is possible to use a solution > like the one used in openbabel: > > AM_CONFIG_HEADER(src/config.h) > ... > AC_CONFIG_COMMANDS([src/libconfig.h], > [cat src/config.h | grep -v PACKAGE >src/libconfig.h]) > > and add #include <config.h> in cpp files when the PACKAGE* variables are > needed (i.e. nowhere in libghemical). I have used the following "config"-headers: libconfig.h in libghemical appconfig.h in ghemical I used names other than simply "config.h" so that the header file would not so easily mix if other packages also have a file config.h. But if needed I can re-name them again to be even more unique. I have mostly used the config.h style headers just to reduce the amount of all flags and junk that go into the g++ command line. Also when you are debugging or looking how things work, you can see what the settings were in a file but often it's hard to find out those macro settings that were just at the command line. > When compiling ghemical on an amd64, I get lot of messages like this > one: > ./project.cpp:2804: warning: cast from pointer to integer of different > size. Is the above line at cvs HEAD version (1.90)? If yes it looks like this: glPushName(GLNAME_MD_TYPE1); glPushName((i32u) & (* it1)); The problem here seems to relate to OpenGL graphics API, where for selecting objects later some "names" must be given to objects. The "name" is a 32-bit number, so I have just used the memory address (pointer) of the object as it's name. So far it has worked, but in a 64-bit OS this clearly needs to be changed. I just need to re-think this object naming system, to adapt it so that it works also with 64 bit pointers. > This MUST be fixed. It is quite unsafe. If you try to convert the 32 > bits int back to a pointer, you will probably have crashes (it will > occur if the object is on the stack). Yep. > I also think you should use openbabel-2 for gchemical-2. I can help with > that if needed. Thanks. I think I need a few days to try it first, let's then get back into this matter. Regards, Tommi