[Opengrads-devel] Win32 build

[Arlindo da S. <da...@al...>]

All,

  In the past I used to handle the Win32 builds kind of on the side of
the general Unix/Linux builds. I'm trying now to bring it into the
general build framework so that anyone can perform these builds. As it
is right now, the supplibs build out of th box on cygwin and so does
the GrADS binaries. I'm now looking into having the "setup.exe"
packaging as being integrated into the makefile. More on that later.

  One pressing issue is to have the shared extensions working on
Win32. The good new is, I think I got it working. However,  giving to
the particular way Win32 does linking (Linux people usually hates
Windows for that), any shared library (DLL's in Windows parlance) must
have all its external dependencies resolved at DLL creation time,
rather than at run time (as in Linux/Unix). To make a long story
short, this can be accommodated with the following mods to the build
mechanism:

1) In grads.c, rename main() to grads_main();

2) Add a simple file main.c which simply calls grads_main:

int main(int argc, char **argv) {
    return grads_main(argc,argv);
}

The reason for this is because there is a circular dependency in
grads: the main program in grads.c contains functions that are called
by the other files. Another possibility would be to move these
functions from grads.c to a separate file. The main.c options seems
less intrusive to me.

3) In building the grads executable, say gradsc, I propose we first
create a library with all the .o's that would normally go into gradsc,
except for the main.o above, then

a) On Win32, we make this library dynamic (libgradsc.dll) and link

      gcc -o gradsc main.o libgradsc.dll

   This libgradsc.dll is then used to build the dynamic extensions as well.

b) On Linux/Unix, I propose we create a static libgradsc.a instead and then link

      gcc -o gradsc main.o libgradsc.a + $(LIBS)

 The reason for keeping the library static on Linux/Unix is to keep
the changes to a minimum. If you make it dynamic then the user may
need to set LD_LIBRARY_PATH, an inconvenience with no other benefit.
Of course, in practice we would do all of this with libtool.

   Does anybody have any thoughts/suggestions on this? Another
possibility is to handle the Win32 on a branch, which defeats the goal
of having it built by anyone (and makes maintenance harder).

   Pat: I may need your help with libtool/autotools.Does it seem doable to you?

   Happy Holidays to everyone!

       Arlindo

-- 
Arlindo da Silva
da...@al...