[ghemical-devel] Some more build issues.

Jean Bréfort jean.brefort at ac-dijon.fr
Mon Jul 4 06:17:08 EDT 2005


Le lundi 04 juillet 2005 à 09:03 +0300, Tommi Hassinen a écrit :
> 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.

I understane, but the problem is that bowt hdefiune PACKAGE_NAME and two
others with different values. re-naming them will not solve the problem.
The AC_CONGIF_COMMAND above just removes the PACKAGE* variables from the
public config file.

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

I did that already for gchempaint (cvs version). See the more recent
commits.
Btw, I could compile ghemical-1.90 on my laptop. It seems I cannot
export molecules from gchempaint to ghemical-1.90. It does not read the
gpr files written using openbabel?

Best regards,
Jean



More information about the ghemical-devel mailing list