From paul.suh at ps-enable.com Thu Nov 1 22:28:51 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Thu Nov 1 22:29:14 2007 Subject: [Newsletter] Leopard's Quick Look and Sandboxing, But Wait!, a Small Bug, Beta LoginWindow MultiScript Message-ID: <7D753363-E49E-4C20-8786-23C74B451F5A@ps-enable.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2615 bytes Desc: not available Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20071101/d43cbb4b/smime.bin From paul.suh at ps-enable.com Wed Nov 14 08:08:18 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Wed Nov 14 08:08:43 2007 Subject: [Newsletter] Create_release Script Message-ID: <7D5F527C-366A-4EE7-9A9D-9CEDBBD43331@ps-enable.com> Folks, Just one big thing this time around. Creat_release Script ------------------------------------- Part of the software release process is creating the final .dmg file containing everything -- the application or installer package(s), documentation, the source code (if the app is open source), etc. Part of a rigorous software testing process is to install the package on a testbed machine from the shipping configuration -- i.e., off of the disk image. As a result, when I develop software I need to constantly create release-ready .dmg files with everything ready to go. This becomes even more important for larger software development teams. In many cases they will have separate Quality Assurance engineers whose job it is not to write code but to look for problems. In a really large software development organization, there are separate coding, build, and QA sections. The coders will write stuff and check it in to the repository. At regular intervals, the build team will check out a fresh copy of the full source from the repository and try to build it. Sometimes it will fail as one programmer made a mistake, or perhaps two programmers made conflicting changes. If the project builds, then the QA people go to work and see if it passes their tests. In this situation, it's absolutely essential that the build process be fully automated all the way to the end, since the build team may have no idea what the different pieces are and where they should go. While the set of tasks is not complex, it is long and tedious. Let's look at what needs to happen: 1) Create a properly named scratch directory. 2) If shipping an installer package, build the package using either Package Maker or Iceberg. 3) Copy the .pkg or the application into the scratch directory. 4) Copy any associated documentation files (ReadMe, License, etc.) into the scratch directory. 5) If I'm releasing the application open source, create a source code scratch directory. Otherwise, skip to step 6) Copy the whole project directory to the source code scratch directory. 7) Strip out any build subdirectories from the source code scratch directory. 8) Package up the source code using gnutar. 9) Copy the source code package into the .dmg scratch directory. 10) Build the .dmg file from the scratch directory. 11) Delete the scratch directory, since we need to start fresh the next time. That's a lot of fairly finicky work to do manually. Far better to automate this -- and XCode makes it easy with Target dependencies and shell script steps. What is a target? To quote from the XCode documentation: > The organizing principle of the Xcode build system is the target. A > target contains the instructions for building a finished product > from a set of files in your project?for example, a framework, > library, application, or command-line tool. Each target builds a > single product. A simple Xcode project has just one target, which > produces one product from the project?s files. A larger development > effort with multiple products may require a more complex project > containing several related targets. For example, a project for a > client-server software package may contain targets that create a > client application, a server application, command-line tool > versions of the client and server functionality, and a private > framework that all the other targets use. In my projects I define a Create_release target. Since a target can depend on a target, I make the Create_release target depend on the primary target for the project. Thus, XCode will make sure that the primary target for the application will be built before it tries to run this target. The rest of the target contains a Shell Script step. This runs a script that does all of the above steps. I've refined the script step over the years. At first, almost everything was hard- coded. As I took the script and re-used it in more projects, I took advantage of XCode's ability to pass in information about the project in environment variables. After reading a neat posting by James Duncan Davidson, I incorporated some additional ideas about setting the human-readable version, testing for the build variant (must be "release", not something else), and automatically uploading the build to a server. He also has some really clever ideas on how to modify any associated appcast XML to notify users that a an updated version of the app is available. James's blog posting is at: . My script is at: . This version is intended for Leopard -- but I am actively working to roll support to Tiger into it as well. The problem is that XCode 2.4 (I haven't tried it on 2.5) does not pull in .xcconfig file settings into Shell Script targets. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2615 bytes Desc: not available Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20071114/072f5010/smime.bin From paul.suh at ps-enable.com Mon Nov 26 23:44:31 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Mon Nov 26 23:44:52 2007 Subject: [Newsletter] Mobile Accounts for Laptop Carts, Hilarious Spam, Build Numbers Message-ID: <98C6F8F9-CB94-4D5F-8DDE-C5EED293C595@ps-enable.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2615 bytes Desc: not available Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20071126/40538a02/smime.bin