[GRASS5] New makefiles - work in progress, take 'em for a spin

Attached is a .tgz of the new makefile work I've been
up to. If you're adventurous, try it out as follows:

1) from within the top level grass distribution directory
  gunzip -cd grass.remake.tgz | tar xvf -

2) if you're using Linux, you'll probably be ok. If not,
    you'll have to copy the contents of src/CMD/head/head
    into the include/Make/Platform.make file. There are
    a handful of macro definitions at the end of the file
    that will need to be edited for your platform of choice.

3) type "make"

4) get coffee, tea, or non-caffeinated beverage and
    enjoy the show.

5) type "make install" and watch a bunch of files get
    copied to locations under $GISBASE/$ARCH. Note that
    files that can be shared by multiple platforms can
    be in the same installation tree, as the platform
    specific files are installed under unique subdirs.

6) let me know if I'm on the right track here, and should
    bother with completing the makefiles, editing startup
    scripts to use the shared libs, etc.

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

(attachments)

grass.remake.tgz (14.6 KB)

Hi Eric.

I did a quick run on your new Makefiles on Win32 using Cygwin but I run into
problems straight away:

make[1]: Entering directory `/cygdrive/f/source/cvsroot/grass/src'
make[2]: Entering directory `/cygdrive/f/source/cvsroot/grass/src/libes'
make[2]: Leaving directory `/cygdrive/f/source/cvsroot/grass/src/libes'
make[1]: Leaving directory `/cygdrive/f/source/cvsroot/grass/src'
make[1]: Entering directory `/cygdrive/f/source/cvsroot/grass/src'
make[2]: Entering directory `/cygdrive/f/source/cvsroot/grass/src/libes'
make[3]: Entering directory
`/cygdrive/f/source/cvsroot/grass/src/libes/vask'
ld -s -shared -lc \
V_call.o V_clear.o V_const.o V_exit.o V_init.o V_line.o V_ques.o V_error.o
V_support.o V_acc.o V_trim_dec.o V_tty.o -o libvask.so
V_call.o(.text+0x99):V_call.c: undefined reference to `_alloca'
V_call.o(.text+0x10a):V_call.c: undefined reference to `stdscr'
V_call.o(.text+0x110):V_call.c: undefined reference to `wmove'
V_call.o(.text+0x132):V_call.c: undefined reference to `stdscr'

etc.

I gather from this that you're aiming to produce a shared lib (.so) under
Unix and presumably a DLL under Windows, for each subdir in libes.

If so, things are more complicated under Windows than for Unix, as Windows
DLL's don't work the same as Unix shared libraries. Let me know what your
intention is, and I'll try and help out from the Windows side.

To further complicate matters, I'm not certain what the relationship between
Cygwin .so libraries and Windows DLL's might be - I'm diving into the docs
now to find out.

Cheers

Mike Thomas.

----- Original Message -----
From: Eric Mitchell <emitchell@altaira.com>
To: <grass5@geog.uni-hannover.de>
Sent: Friday, 4 August 2000 12:35 AM
Subject: [GRASS5] New makefiles - work in progress, take 'em for a spin

Attached is a .tgz of the new makefile work I've been
up to. If you're adventurous, try it out as follows:

1) from within the top level grass distribution directory
gunzip -cd grass.remake.tgz | tar xvf -

2) if you're using Linux, you'll probably be ok. If not,
    you'll have to copy the contents of src/CMD/head/head
    into the include/Make/Platform.make file. There are
    a handful of macro definitions at the end of the file
    that will need to be edited for your platform of choice.

3) type "make"

4) get coffee, tea, or non-caffeinated beverage and
    enjoy the show.

5) type "make install" and watch a bunch of files get
    copied to locations under $GISBASE/$ARCH. Note that
    files that can be shared by multiple platforms can
    be in the same installation tree, as the platform
    specific files are installed under unique subdirs.

6) let me know if I'm on the right track here, and should
    bother with completing the makefiles, editing startup
    scripts to use the shared libs, etc.

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | file://--==\ |L--/ || file://--==\ || || "=,
          \ ---===/
           \____---===/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hello Eric

I haven't looked at them closely yet (and I don't know if I'll have time to do
so) but offhand it looks pretty good. The only comment I have now is that, like
somebody posted a few days ago, I think naming the files in the include
directory Makefile.* instead of *.make is better since it conforms to the
pseudo-standard style used in many other software packages. If I get a chance,
I'll give it a try on our SGI and let you know of any problems I encounter.

Thank you for taking on this project!

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hello Eric

I was looking into running your Makefiles on our SGI and your instructions to
change a few variables at the end of Platform.make say I need to provide
something for the RANLIB variable. SGI does not have ranlib and the LIBRULE in
our head file is:

LIBRULE = ar ruv $@ $?; : $@

as opposed to your LIBRULE which is:

LIBRULE = ar ruv $@ $?; ranlib $@

I have no idea what ranlib does or what the equivalent command on SGI would be.
Do you have any ideas as to what I should set RANLIB to? Should I leave it
blank? It appears that the LIBRULE does not replace it with anything.

Also, why can't GRASS_HOME be GISBASE?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Fri, Aug 04, 2000 at 03:42:42PM +0000, Justin Hickey wrote:

I have no idea what ranlib does or what the equivalent command on SGI
would be. Do you have any ideas as to what I should set RANLIB to?
Should I leave it blank? It appears that the LIBRULE does not replace
it with anything.

ranlib creates an index in an binrary archive. This is needed by
some linkers to make it a loadable library.
Some platforms just don't need it.

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

Justin Hickey wrote:

Hello Eric

I was looking into running your Makefiles on our SGI and your instructions to
change a few variables at the end of Platform.make say I need to provide
something for the RANLIB variable. SGI does not have ranlib and the LIBRULE in
our head file is:

LIBRULE = ar ruv $@ $?; : $@

as opposed to your LIBRULE which is:

LIBRULE = ar ruv $@ $?; ranlib $@

I have no idea what ranlib does or what the equivalent command on SGI would be.
Do you have any ideas as to what I should set RANLIB to? Should I leave it
blank? It appears that the LIBRULE does not replace it with anything.

ranlib restructures the library for more efficient random
access. "RANLIB = true" should do the trick for platforms
that don't have/require ranlib.

Also, why can't GRASS_HOME be GISBASE?

Work in progress taken from other project that uses NAME_HOME
instead of NAMEBASE. The GRASS_HOME references should be changed
to GISBASE.

Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th

--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hello Bernhard

ranlib creates an index in an binrary archive. This is needed by
some linkers to make it a loadable library.
Some platforms just don't need it.

Thanks for the information. I'll just leave it blank.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Eric.

as "DLL". If the "normal" installation method works on
CygWin, try the following from a clean start:
make install |& tee grass-5.0b8-cygwin.log

I've never been able to get a working build using the normal method! Apart
from the practical advantages of a proper makefile system, this is the
reason I'm trying your makefiles out.

Attached are a couple of altered files which show what needed to be done to
get the Cygwin Windows shared library build working for libes/vask.

Notes:

1. I've changed shlib.make to allow construction of the dll, the def and
the corresponding .a import lib (eg libvask.dll, libvask.def and libvask.a)
under Windows. These changes include some new variables set up in
platform.make at the bottom:

----------------------------------------------------------------------------
--------------------------
SHLIB_PREFIX = lib
SHLIB_SUFFIX = .dll
SHCFLAGS =
SHLDFLAGS =

# The Export definitions
DEFLDFLAGS = --export-all-symbols --driver-name gcc --output-def
DEF_PREFIX = lib
DEF_SUFFIX = .def

# The DLL import library definitions
IMPLDFLAGS = --output-lib
IMP_PREFIX = lib
IMP_SUFFIX = .a
----------------------------------------------------------------------------
--------------------------

2. To allow this system to work under Unix, (as yet untried) I've moved the
dot "." in the file extension out of shlib.make and into platform.make.
This allows the Unix make variables to be blank, while the Windows variables
are filled out and vice-versa. No extraneous dots in the final command
line.

3. I've added -lncurses into the vask Makefile via the EXTRA_LIBS variable.

4. By making each libe/* lib into a DLL, we are forced to resolve all
external references. This means that cross dependencies will need to be
taken care of by carefully ordering the libes build and copying the
resulting DLL's and import libraries into some central location. An example
of this cross dependency problem is:

----------------------------------------------------------------------------
--------------------------
make[3]: Leaving directory `/cygdrive/f/source/cvsroot/grass/src/libes/vask'
make[3]: Entering directory
`/cygdrive/f/source/cvsroot/grass/src/libes/segment'
dllwrap -s \
  address.o flush.o format.o get.o get_row.o init.o pagein.o pageout.o put.o
put_row.o release.o seek.o setup.o \
--export-all-symbols --driver-name gcc --output-def libsegment.def \
--output-lib libsegment.a \
-o libsegment.dll
dllwrap: no export definition file provided
dllwrap: creating one, but that may not be what you want
format.o(.text+0x131):format.c: undefined reference to `G_warning'
----------------------------------------------------------------------------
--------------------------

I'm looking into how to sort this out.

We could always rig it up so that libraries are built
statically on Windows for now.

This is an option. You could finally build a big grass.dll at the end. It
has the disadvantage of being less efficient (small modules have to load
EVERYTHING).

It has the advantages of simplicity and avoiding the crossdependency
problem.

I've often thought that
rewriting the Windows dynamic linker would be easier
than hassling with when to __declspec(DLLIMPORT) and
__declspec(DLLEXPORT).

Go ahead!!!

I'm not 100% certain that it will be necessary to do this, as it seems that
the dllwrap tool allows you to export all symbols automatically. I'm
uncertain whether this has implications at run/link time or not - I'll find
out once I get the libes built.

> To further complicate matters, I'm not certain what the relationship

between

> Cygwin .so libraries and Windows DLL's might be - I'm diving into the

docs

> now to find out.

I'm talking rubbish late at night - there are no Cygwin .so libraries. I'm
on a Cygwin learning curve. The latest version is much nicer than Beta
20.1.

Let me know what you find. Thanks for trying it out.

A pleasure - I'm still hoping to see a working version of Grass on my
computer one day! I'll keep hacking on with the problems I've mentioned.

Cheers

MIke Thomas

(attachments)

Shlib.make (2.42 KB)
Platform.make (1.92 KB)
Makefile (1.13 KB)

Hi Eric.

I spent all day trying to get the each of the libes to compile and link as
DLL's but I'm afraid that the interdependencies in the vect32 directory have
gotten the better of me.

By rearranging some of the files in diglib and vlib I got "diglib" compiled,
but then I was caught by the digitiser dependencies in vlib (D_*).

This sounds like a can of worms to me. Unless someone has some suggestions
I agree with your suggestion that the Cygwin libes be compiled as static
libs and then maybe make one big DLL at the end.

Cheers

Mike Thomas.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'