On Mon, May 29, 2017 at 7:02 PM Jame Eshelman wrote: > However the > postings I read from the early days of OS X on doing this ran to many > pages, even aside from GUI issues.
At a previous job, we had a large internal product that consisted of a mix of Perl and Python enhanced by a bunch of other stuff (libXML2, Squid, etc.) The entire environment was built from source via a single master Makefile that would pull source from SCM (or pulling latest.tar.gz from the internet in bleading-edge mode) and build it. Developers ran Linux, Solaris, Windows, and OSX. (production hardware was a mix of Linux and Solaris) I was one of the devs running OSX. Although whatever chicanery we needed to build it was hidden in a Makefile, I don't remember it being too bad. (on the other hand, I don't remember what it was either. I've been at the current job nearly 10 years, I can't imagine compatibility getting worse since then.) In some ways, the pattern you are describing with history complaints of the OSX build matches what you would probably see if you looked at the history if perl on Redhat or Activestate. In early incarnations, there were many complaints about how much it diverged from the stock release. By now, the packager release is nearly identical to the standard release. There is probably a bit of back and forth between the vendor (in Perl's case, the Patch Pumpkings) and the packager. Packagers did whatever they needed to do to make the product build within the rest of their environment. They either submitted patches or pumpkings complained about diverged releases. Probably a lot of patches were too specialized, and so Perl was made more generic (remember when we just had "perl Makefile.PL PREFIX=..." ? now we have a whole slew of SITEPREFIX,VENDORPREFIX, INSTALLBIN,INSTALLSCRIPT, etc. all to handle someone's requirements.) _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
