[ghemical-devel] Some more build issues.

[Tommi Hassinen]

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