Loading ...
Sorry, an error occurred while loading the content.

Eliminating StuffIt from the OS X build process (was Re: Panther gVim)

Expand Messages
  • Daniel Sandler
    ... That s for sure. Is there any particular reason that BinHex is being used to encapsulate these Mac resources, rather than something a little easier to
    Message 1 of 23 , Oct 24, 2003
    • 0 Attachment
      > Just a quick note: opening .hqx files can have nasty side effects...

      That's for sure.

      Is there any particular reason that BinHex is being used to encapsulate
      these Mac resources, rather than something a little easier to manipulate
      from make or jam? (That is, something that can be used with blocking
      shell tools?) I have a couple of ideas on how this might be done:


      Suggestion 1: Use the OS X pseudo-file spec to manipulate resources

      Background: Apple's implementation of POSIX file ops for resource-fork
      filesystems seems to provide some pseudo-file paths allowing direct
      access to the different forks of a file as separate file descriptors.
      (There appear to be some relevant #defines in sys/paths.h .)

      Usage: To get started, split gui_mac.rsrc into data and resource
      forks:

      cat gui_mac.rsrc/..namedfork/rsrc > os_mac.rsr.rsrcfork
      cat gui_mac.rsrc/..namedfork/data > os_mac.rsr.datafork

      At this point, you have two files containing only data forks.
      Therefore, they ought to be safe to add to CVS:

      cvs add os_mac.rsr.{rsrc,data}fork

      At build time, reverse the procedure:

      # fictitious Makefile excerpt
      gui_mac.rsrc:
      touch gui_mac.rsrc # need to have the file present first
      cat os_mac.rsr.rsrcfork > gui_mac.rsrc/..namedfork/rsrc
      cat os_mac.rsr.datafork > gui_mac.rsrc/..namedfork/data

      Downside: I believe the ..namedfork spec was introduced in OS X 10.2,
      so you might be limiting the platforms on which vim can be built.

      Another downside: anything I find in a header file delimited by #ifdef
      __APPLE_API_PRIVATE sort of gives me the creeps. It doesn't seem to
      be a well-documented API, and so could go away at any time.
      Information on this API is scarce and sometimes inconsistent; the most
      authoritative note I've seen (read: "comes from an @... email
      address") is here: http://nntp.x.perl.org/group/perl.macosx/4260 .


      Suggestion 2: use DeRez/Rez, part of the OS X developer tools

      This is what I used to store resources in CVS for my OS X projects
      before I learned about the ..namedfork trick.

      Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
      gui_mac_static.r (since gui_mac.r already exists to include dynamic
      stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
      $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.


      I hope this is helpful; I apologize for not submitting proper patches,
      but I'm not set up to build OS X vim at the moment...

      -dan, re-engaging his lurking device
    • Eric Y. Kow
      Folks, Thanks for the discussion. It s been educational. ... As a matter of personal taste, I d avoid this kind of stuff. ... I like this approach much
      Message 2 of 23 , Oct 25, 2003
      • 0 Attachment
        Folks,

        Thanks for the discussion. It's been educational.

        On Fri, Oct 24, 2003 at 15:48:02 -0700, dan sandler dsandler-at-dsandler.org |vim-mac@.../1.0-Allow| wrote:
        > Another downside: anything I find in a header file delimited by #ifdef
        > __APPLE_API_PRIVATE sort of gives me the creeps. It doesn't seem to

        As a matter of personal taste, I'd avoid this kind of stuff.

        > Suggestion 2: use DeRez/Rez, part of the OS X developer tools
        ...
        > Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
        > gui_mac_static.r (since gui_mac.r already exists to include dynamic
        > stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
        > $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.

        I like this approach much better! Especially now that it has been
        blessed by somebody who presumably has clue what's going on :-)

        Is deRez'ing gui_mac.rsrc basically equivilant to de-compiling it?
        If so, would it be too onerous to re-write gui_mac_static.r by hand, or
        find the guy that wrote the original? If we're going to have some kind
        of source around, it might as well be readable, eh?

        --
        Eric Kow http://www.loria.fr/~kow
        PGP Key ID: 08AC04F9 Merci de corriger mon français.
      • Dany St-Amant
        Le vendredi, 24 oct 2003, à 17:31 Canada/Eastern, Daniel Sandler a ... As I always decode it before hand, I never saw an issue. Beside Muraoka s suggestion,
        Message 3 of 23 , Oct 26, 2003
        • 0 Attachment
          Le vendredi, 24 oct 2003, à 17:31 Canada/Eastern, Daniel Sandler a
          écrit :

          >> Just a quick note: opening .hqx files can have nasty side effects...
          >
          > That's for sure.
          >
          > Is there any particular reason that BinHex is being used to encapsulate
          > these Mac resources, rather than something a little easier to
          > manipulate
          > from make or jam? (That is, something that can be used with blocking
          > shell tools?) I have a couple of ideas on how this might be done:

          As I always decode it before hand, I never saw an issue. Beside
          Muraoka's
          suggestion, one could possible use an AppleScript as Stuffit Expander
          accept
          a destination folder through AppleScript.

          > Suggestion 1: Use the OS X pseudo-file spec to manipulate resources

          No can do. This will not work on the pre-MacOS X.

          > Suggestion 2: use DeRez/Rez, part of the OS X developer tools

          This should work fine as both MPW and old CodeWarrior version
          supported Rez.

          > Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
          > gui_mac_static.r (since gui_mac.r already exists to include dynamic
          > stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
          > $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.

          One file should be enough as the current gui_mac.r was extracted from
          the original gui_mac.rsrc to properly propagate the version number.

          Dany
        Your message has been successfully submitted and would be delivered to recipients shortly.