Re: build problem on MacOS X

[John M. <jo...@fa...>]

On Tue, Jul 16, 2002 at 07:34:12AM -0400, Philip Streck wrote:
> On Tuesday 16 July 2002 07:18 am, Zeno Crivelli wrote:
>> but there are some "gaps" in the OSX side which is of course completely
>> normal since you don't own a Mac.

Or it could be that I know more than I'm letting on... :-)

>>> It appears that --with-palmdev-prefix=/Developer/PalmDev
>>> would be entirely suitable on Mac OS X [...]
>>> Perhaps "/Developer/Palm OS Support" or so would be even nicer
>>
>> No, both possibilities are bad for a Mac OS X user and I tell you why:
[...]
>> So putting PRC-Tools command-line
>> binaries there, it'll destabilize the Mac OS X "2 worlds" concept.

You misunderstand.  Noone is suggesting that.  (Various Windows idiots
insist on putting the binaries under C:\PalmDev, but that's *in spite of*
what I suggest, not because of it.)

> /Developer is good for the PalmDev directory not the binarys though.

Perhaps I was unclear.  $prefix (--prefix) controls where the binaries
and such are installed; $palmdev_prefix (--with-palmdev-prefix) specifies
where prc-tools will look by default for separately installed publicly
visible things like SDKs.

We (three) are all in agreement:  $prefix should be somewhere
"invisible" such as /usr (hence /usr/bin, /usr/lib, etc), while
$palmdev_prefix should be somewhere "visible" (e.g. /Developer/PalmDev
on Mac OS X, /opt/palmdev on FHS platforms, C:\PalmDev on Windows).

> I think 
> we should install sdk's documentation, example files etc... in 
> /Developer/PalmDev because it IS a visible  folder.

That is SEP (somebody else's problem).  Prc-tools itself has no interest
in SDK documentation or examples.  It's only interest is in *looking
for* SDK headers and libraries, not in installing them.

(Let's take SDK examples as an example.  How does a developer really use
the examples?  Perhaps they keep them pristine somewhere for reference.
Perhaps they "install" them read/write in their own local user directory
somewhere and tweak and add to and compile them.  Perhaps they have
several copies.  Certainly every developer is different, and there's no
standard place to install them.  For these reasons, attempting to package
manage them is a waste of time, and they ought to be made available in
their own separate dumb (.tar.gz/.zip/.sit) archive for maximum
flexibility.  Oddly, Palm(Source) had this exactly right in the 4.0 SDK
but has since completely bungled it in the 5.0 SDK.  But I digress...)

    John