[GRASS-dev] include/portable.h?

Hi,

I wonder if the file 'portable.h' is installed
into the right directory:

cd grass61/lib/vector/diglib
grep portabl Makefile | grep include
        $(INSTALL) -m 644 portable/i386-pc-mingw32msvc.h $(ARCH_DISTDIR)/include/portable.h
        echo "/* Architecture: $(ARCH) */" > $(ARCH_DISTDIR)/include/portable.h
        $(OBJDIR)/port_test >> $(ARCH_DISTDIR)/include/portable.h

-> shouldn't it be $(ARCH_DISTDIR)/include/grass/portable.h
?

Markus

At least in last weekend's snapshot, it does both:

  $(CC) $(LDFLAGS) $(COMPILE_FLAGS) $(VECT_CFLAGS) $(INC) $(VECT_INC) -o $(OBJDIR)/port_test port_test.c
  echo "/* Architecture: $(ARCH) */" > $(ARCH_INCDIR)/portable.h
  $(OBJDIR)/port_test >> $(ARCH_INCDIR)/portable.h
  echo "/* Architecture: $(ARCH) */" > $(ARCH_DISTDIR)/include/portable.h
  $(OBJDIR)/port_test >> $(ARCH_DISTDIR)/include/portable.h

On Jun 30, 2006, at 10:52 AM, Markus Neteler wrote:

Hi,

I wonder if the file 'portable.h' is installed
into the right directory:

cd grass61/lib/vector/diglib
grep portabl Makefile | grep include
        $(INSTALL) -m 644 portable/i386-pc-mingw32msvc.h $(ARCH_DISTDIR)/include/portable.h
        echo "/* Architecture: $(ARCH) */" > $(ARCH_DISTDIR)/include/portable.h
        $(OBJDIR)/port_test >> $(ARCH_DISTDIR)/include/portable.h

-> shouldn't it be $(ARCH_DISTDIR)/include/grass/portable.h
?

Markus

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

Speaking of portable.h, I had to mess with this recently so I could get a Universal Mac binary. It involves saving a copy configured on both platforms and creating a custom portable.h which is conditionalized on __BIG_ENDIAN__ (an OS X compiler def).

Would it be possible to somehow make this so it doesn't need to be generated at compile time? or make it cross-compiler friendly? Or maybe there is already an option for that? Or some other way of handling this architecture endian/size thing. Something to make a Universal build on OS X simpler. Other than getting the universal build flags in the right place, this is the main sticky point for an easy universal build.

The only other alternative is separate builds on each architecture. Then lipo to merge them together.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

William Kyngesburye wrote:

Speaking of portable.h, I had to mess with this recently so I could
get a Universal Mac binary. It involves saving a copy configured on
both platforms and creating a custom portable.h which is
conditionalized on __BIG_ENDIAN__ (an OS X compiler def).

Would it be possible to somehow make this so it doesn't need to be
generated at compile time? or make it cross-compiler friendly? Or
maybe there is already an option for that? Or some other way of
handling this architecture endian/size thing. Something to make a
Universal build on OS X simpler. Other than getting the universal
build flags in the right place, this is the main sticky point for an
easy universal build.

The ideal solution would be to re-write portable.c so that it doesn't
depend upon the host's byte order; i.e. [de]serialize in the correct
byte-order to start with, rather than assuming that the host's
byte-order matches that of the file then "byte-swap" if it doesn't.

Alternatively, most of portable.h could be generated by the configure
script, using the AC_CHECK_SIZEOF and AC_C_BIGENDIAN macros. However,
the latter only accounts for the simple cases; it doesn't handle
mixed-endian architectures (primarily some ARM-based platforms; I
don't think that the PDP-11 needs to be supported).

--
Glynn Clements <glynn@gclements.plus.com>

On Jul 1, 2006, at 1:58 PM, Glynn Clements wrote:

The ideal solution would be to re-write portable.c so that it doesn't
depend upon the host's byte order; i.e. [de]serialize in the correct
byte-order to start with, rather than assuming that the host's
byte-order matches that of the file then "byte-swap" if it doesn't.

Maybe I should add a wish for this? Or could you, since you seem to understand what to ask for?

This is the only place I've found in GRASS right now with endian-dependent code. Could something like this make it into the 6.2 release?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy