[GRASS-dev] some GRASS source and packaging observations and questions

William_Kyngesburye · December 15, 2006, 9:23pm

While working on an Xcode project for GRASS (almost ready, just needs some testing), I came across a few oddities, and have a couple questions. I submitted a couple bugs, these are leftovers that I'm not sure about their bug-ness.

- r.li - its library is named libr_li, or the full file name: liblibr_li.[libext]. This doesn't really fit in with the libgrass_[foo].[libext] naming of GRASS.

- r3.in|out.v5d - these are built by default, but I noticed in the source that they are big-endian-only, with comments that little-endian byte-swapping code is needed. It looks like there was a start at it, as binio.c accepts a -DLITTLE flag, and a couple places (but not all) have byte-swap code.

If these are in such a state, they probably shouldn't be built by default.

- bin/scripts - I'm curious if there is a practical reason to separate compiled progs and scripts into bin and scripts folders? Maybe some have the scripts folder name hardcoded in them for some reason, or maybe in the GUI?

Basically they are all executables, and it adds another path item needed in the PATH env. (And I need to deal with a possible/rare case-sensitivity problem in a Mac app package between 'scripts' and 'Scripts'.)

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

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

Glynn_Clements1 · December 16, 2006, 1:25pm

William Kyngesburye wrote:

While working on an Xcode project for GRASS (almost ready, just needs
some testing), I came across a few oddities, and have a couple
questions. I submitted a couple bugs, these are leftovers that I'm
not sure about their bug-ness.

- r.li - its library is named libr_li, or the full file name:
liblibr_li.[libext]. This doesn't really fit in with the libgrass_
[foo].[libext] naming of GRASS.

If it's meant to be a "public" library, it should be added to
include/Make/Grass.make.in, and should have the "grass" prefix.

- r3.in|out.v5d - these are built by default, but I noticed in the
source that they are big-endian-only, with comments that little-
endian byte-swapping code is needed. It looks like there was a start
at it, as binio.c accepts a -DLITTLE flag, and a couple places (but
not all) have byte-swap code.

If these are in such a state, they probably shouldn't be built by
default.

Agreed.

- bin/scripts - I'm curious if there is a practical reason to
separate compiled progs and scripts into bin and scripts folders?
Maybe some have the scripts folder name hardcoded in them for some
reason, or maybe in the GUI?

Basically they are all executables, and it adds another path item
needed in the PATH env. (And I need to deal with a possible/rare
case-sensitivity problem in a Mac app package between 'scripts' and
'Scripts'.)

Until recently, there wasn't any compelling reason for having separate
directories.

However, Paul Kelly recently figured out a simple and effective way to
make Bourne-shell scripts work natively on Windows: for each script,
install a corresponding .bat file (in the bin directory) which
explicitly invokes the shell on the script (in the scripts directory).

In that situation, it makes sense to have separate directories, as the
scripts are essentially data files (for use by the shell interpreter)
rather than executables in their own right. Only the bin directory is
added to the path.

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

William_Kyngesburye · December 16, 2006, 8:39pm

On Dec 16, 2006, at 7:25 AM, Glynn Clements wrote:

- bin/scripts - I'm curious if there is a practical reason to
separate compiled progs and scripts into bin and scripts folders?
Maybe some have the scripts folder name hardcoded in them for some
reason, or maybe in the GUI?

Basically they are all executables, and it adds another path item
needed in the PATH env. (And I need to deal with a possible/rare
case-sensitivity problem in a Mac app package between 'scripts' and
'Scripts'.)

Until recently, there wasn't any compelling reason for having separate
directories.

However, Paul Kelly recently figured out a simple and effective way to
make Bourne-shell scripts work natively on Windows: for each script,
install a corresponding .bat file (in the bin directory) which
explicitly invokes the shell on the script (in the scripts directory).

In that situation, it makes sense to have separate directories, as the
scripts are essentially data files (for use by the shell interpreter)
rather than executables in their own right. Only the bin directory is
added to the path.

I noticed the discusion on that, just didn't pay attention to it

There are explicit references to scripts in init.sh - for checking the availability of the GUIs before trying to start them. I guess that means I'll leave scripts in Scripts for now and my new OSX GRASS.app startup won't run on a case-sensitive Mac file-system. But, running anything on a Mac case-sensitive file system in generally not recommended. Heck, using a case-sensitive HFS+ or UFS on OSX at all is not recommended.

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

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

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

H_B · December 18, 2006, 7:46am

Hi,

AFAIK you can drop "GD" from frameworks. It isn't used anymore. Also, it
would be nice if the AllFrameworks.dmg installer allowed you to deselect
packages in the Customize menu.

Also I am not sure if it is worth mentioning GLw/r3.showdspf at all in
the README as it isn't switched- it requires a Makefile hack to enable.

Hamish

William_Kyngesburye · December 18, 2006, 3:35pm

On Dec 18, 2006, at 1:46 AM, Hamish wrote:

Hi,

AFAIK you can drop "GD" from frameworks. It isn't used anymore.

GD is used in MapServer. I was just being lazy in the GRASS.app readme, saying it needs all the frameworks. (PDFlib is also not needed by GRASS, but otherwise all the other frameworks are needed)

Also, it
would be nice if the AllFrameworks.dmg installer allowed you to deselect
packages in the Customize menu.

I tried that once with the MapServer installer, but it never worked (same problem), so I switched to multiple installers. I didn't worry about it for the all frameworks installer. There must be a trick to get it working. I have a note in my low-priority todo list, so someday I'll figure it out.

Also I am not sure if it is worth mentioning GLw/r3.showdspf at all in
the README as it isn't switched- it requires a Makefile hack to enable.

Hm, I guess if it's not something one would consider a part of a standard GRASS...

Thanks for the comments

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