Re: [MacPerl-Porters] installation thoughts

At 13:24 Uhr -0400 17.09.2001, Chris Nandor wrote:
>Your thoughts are solicited.
>
>I am working through the installer, and my current plan is to have two
>installers: one standalone with everything, and one web-based one (so you
>only download what you need).
>
>So I am trying to figure out what installation packages we want/need, and
>how to link them together.
>
>Right now, I have the following sketched out, not in stone at all.
>
>Installation Packages
>	* Documentation
>	* Test files
>	* All-static builds (68K, PPC, FAT?)
>	* All-dynamic builds (PPC) (default?)

>	* All-static builds (68K, PPC, FAT) with -DDEBUGGING ?
>	* All-dynamic builds (PPC) with -DDEBUGGING ?

>	* MPW Tool (-DDEBUGGING, static, dynamic ?)
>
>	* SYM files ?
>	* Source ?
>
>I am thinking four different main binaries: 68K static, PPC static, FAT
>static, and PPC dynamic.  On top of that, I wonder whether or not to
>include -DDEBUGGING binaries of each.  On top of that, I wonder if the same
>4/8 options should apply to MPW tools.  That would give 16 different
>binaries, which I am not really opposed to.  But am I missing something?
>Or including something unnecessary?
>
>I have yet to do benchmarking on static vs. dynamic; it may be that static
>PPC is unnecessary.  If it doesn't benefit from speed, I might just not do
>a static PPC build at all.  

You should also consider the load time of a static vs. dynamic perl binary.

>Also, if -DDEBUGGING does not cause significant
>slowdown, I will just include it by default (it has been included in all
>alphas so far).  So that would bring us to just 6 total binaries, app/tool
>68K/PPC/FAT.
>
>I figure Shuck should just be FAT, if we can swing it.

I'm working on it ;-)

>
>And then there is the idea of including the SYM files and the source, so
>people can go through the debuggers if they want to.

People who like debugging will probably be able to build the sources themselves; after all it's not too hard to follow the build recipe. And SYM-files  are no lightweights, so I wouldn't include them at all.

>
>Thoughts?
>

What about

  - Documentation
  - Library
  - Tests
  - 68K static app
  - 68K static tool
  - PPC dynamic app (with shared libs for extensions)
  - PPC dynamic tool (with shared libs for extensions)
  - Source, as currently distributed with documentation and tests

Let me explain:

I personally don't like FAT binaries as I don't see their need. If I have a 68K Mac, I need the 68K binary, if I have a PPC Mac, I need the PPC binary, if I have both, I can get both distributions. What about separating the binaries by architecture (68K, PPC), where 68K is generally static, and PPC is generally dynamic. I don't worry about the -DDEBUGGING switch; as you said, if there's no speed penalty, just leave it in (don't confuse people). Then, make the Perl library a separate package. This means, that the PPC app and tool should come with all needed shared libraries for their extension modules (i.e. the :lib:MacPPC: directory).

So, to get a full MacPerl environment, you choose 

Documentation + Library + Perl app and/or tool binary for your architecture  + Tests


Does that make sense (I'm a bit tired :)? IIRC, Albert Einstein once said:

    "Make it as simple as possible, but not simpler."  ;-)


Best regards,

--Thomas


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com