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

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

Expand Messages
  • 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 1 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 2 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.