Subject: Re: New Developer Tools CD
Cc: projectbuilder-users@lists.apple.com
To: Mike Ferris <mferris@apple.com>
From: Mike Ferris <mferris@apple.com>
Sender: projectbuilder-users-admin@lists.apple.com
List-Archive: <http://www.lists.apple.com/archives/projectbuilder-users/>
Date: Fri, 19 Apr 2002 17:44:30 -0700
Lovely. "demime". :-)
Now I'm wondering how to get the rel note content out...
Guess it'll have to be plain text. See the bottom of this message, they're not as pleasantly formatted as I might like, but the content is all there.
Begin forwarded message:
From: Mike Ferris <mferris@apple.com>
Date: Fri Apr 19, 2002 05:25:53 PM US/Pacific
To: projectbuilder-users@lists.apple.com
Subject: New Developer Tools CD
We have been informed that the April 2002 Developer Tools CD will become
available for download to all ADC Software Seed Key Holders today. Over
the next week it will be gradually rolled out to wider groups of folks
and by the end of next week should be available for download to all ADC
members.
This release will be going out in the next monthly ADC mailings as well.
This new release is a public Beta. It includes Project Builder 2.0 Beta
and it contains a Beta release of the new gcc 3.1 compiler. The CD will
also include the December 2001 Tools release (since that is the last GM
release including the update patch that was made available a while ago.
Enjoy,
Mike Ferris
PS. Here's the release notes from Project Builder in case folks are
wondering what's new.
[demime 0.98b removed an attachment of type application/rtf which had a name of PB2.0_ReleaseNotes.rtf]
Project Builder 2.0 Beta
Welcome to the Beta release of Project Builder 2.0! This release has the largest collection of new features and changes since our first release and we feel it has earned the major version bump. The majority of features planned for 2.0 are in place and this version of PB (and it's incremental versions) have been used internally at Apple during most of it's development. We are confident that this version is stable enough for day-to-day development, but bear in mind that as a Beta release it has not received the level of testing we would perform for a full GM-quality release. As always and especially since this is a Beta release, we encourage feedback and bug reports. Please send feedback to macosx-tools-feedback@group.apple.com and/or report bugs and feature requests using bugreporter at
http://developer.apple.com/bugreporter.
Important Notes
Projects will be upgraded
This release of Project Builder, like most previous release, upgrades project files when you open projects for the first time. Projects which have been upgraded should not be reopened in older versions of Project Builder. Since this is a prerelease of the tools, you may want to consider whether you wish to commit yourself to upgrading any particular project. You can always use this release of Project Builder on a copy of your project to try it out.
Clean rebuilds and re-indexing required
For indexing to work correctly with this version of Project Builder, you MUST remove your indices and rebuild your projects from scratch.
To do this, open your project, select the project entry in the Files pane (the top item in the list), choose Show Info from the Project menu, click the Rebuild Index button, and answer yes when it asks you if you want to clean your project. The indexing data structures have changed in this release and old indices will no longer be valid.
Check Syntax is temporarily broken
Single-file syntax checking does not work in this release. This is because there has not yet been time to adapt it to the significant cleanup of the build setting expansion pipeline (which is discussed in more detail below). Single-file syntax checking will be restored for the final release of 2.0. By moving it on top of the improved expansion support we expect that many of the bugs that have plagued it in the past to disappear.
No Japanese Localization
Because this is a Beta release we have not localized into Japanese. All our internationalization features are still there of course, but it is not possible in this release to have the PB interface in Japanese.
Cocoa-Java Indexing
In this release, the java versions of the Cocoa classes will not be automatically indexed in Cocoa-Java projects. We will be correcting this. In the meantime, you can get them to be indexed by adding the folder /System/Library/Java/com/apple/cocoa as a folder reference to your project (in the Add Files options dialog, make sure that Create Folder References for any added folders is selected and command-click any selected targets in the target list to prevent the folder from being added to any targets). You can add any jar files or folders containing class files to your project to have them indexed.
Multiple Developer Tools installations not supported
This has always been the case and is something we plan to address in a future release, but since this is a Beta release it is worth mentioning that you cannot have two different sets of developer tools installed. The only way this can be done is to actually have two full OS installs on different partitions (with different versions of the developer tools installed on each) and to boot from one or the other partition. Obviously this is not a great solution.
New Features
A major new feature in Project Builder 2.0 is a set of preferences and capabilities allowing developers to customize the way the UI works. In particular, it gives you control over what development tasks occur in which windows. There are a number of distinct features that work together to provide this new flexibility. This section details these features, starting with the simplest aspects and progressing on to discuss the more advanced options that allow finer-grained customization.
Factory Provided Choices
The easiest way to choose the behavior you want is to use one of the three factory defaults that ship with Project Builder. We hope that these default configurations will cover the needs of most users.
When you first run Project Builder 2.0 the New User Assistant will ask you to choose one of these three configurations. Later, you can change between them at any time using the Task Templates pane of the Preferences dialog. The three choices are: Single Window, Some Windows, and Many Windows.
Single Window
This configuration gives you the same behavior as in previous versions of Project Builder. Each project has one window and all tasks are performed in this window.
Some Windows
This configuration uses a single window for project navigation, file editing, target editing, and class browsing. However, batch finds, building, debugging, and running occur in separate windows. The main project window has no horizontal sliding tabs. Instead, when you ask for the batch finder, begin a build, or start the debugger, a new window tailored for the purpose will be created. By default there will still be only one find window, one build window, one debug window, and one run window at any time.
Many Windows
This configuration uses separate windows for every task. This is the closest factory preset to the way that CodeWarrior works. The main project window is tall and thin and has no horizontal tabs and no attached editor. Double-clicking files opens them in their own editor windows (one per file). Target editing and class browsing are done in separate windows. Finding, building, running, and debugging (as in the Some Windows configuration) also occur in their own windows.
In the Preferences pane there is a fourth choice "Custom Settings". This choice is available if you've made changes in the Expert Configuration tab such that your settings are different from any of the three default configurations (more on this below).
Tasks and Their Assigned Templates
While the three default configurations described above provide a range of behaviors to choose from, these choices only reflect what we consider to be the most commonly desired configurations of an underlying set of preferences that are much more flexible. The Task Templates pane of the Preferences dialog presents these three main choices in its Basic tab, but there's also an Expert Configuration tab, which displays the underlying settings and lets you customize them if none of the default configurations match exactly what you want. Before explaining the Expert Configuration tab, though, we need to talk about tasks and templates.
Project Builder 2.0 defines a number of tasks that developers use the IDE for. These tasks are the main activities available in Project Builder such as editing, class browsing, accessing help (documentation), finding text or symbol definitions, building, debugging, editing targets, editing project contents, and running executables. Each of these tasks is assigned to a specific window configuration (a window layout template) that will be used whenever that task is invoked. Project Builder provides a set of default window templates that can be assigned to these tasks (developers can change these templates or define their own templates, but that's even more advanced and is discussed later). In addition to its assigned template, each task also can be set to reuse an existing window or create a new one whenever the task is performed.
Each of the default configurations is actually just a different set of task settings. Open the Task Templates Preferences dialog and switch to the Expert Configuration tab. You will see the task assignments for the configuration you currently have in effect. Switch to the Basic tab and choose a different configuration, then go back to the Expert tab and notice the different settings. If you make changes in the Expert tab and Apply them, you'll notice that the "Custom Settings" button will now be selected in the Basic tab. Project Builder remembers the last settings you had that were different from the factory preset configurations and you can get back to them by selecting the "Custom Settings" button.
The Expert Configuration tab lists all the tasks and for each one there is a popup that lets you choose which template is assigned to that task and a checkbox that lets you specify whether windows for this task should be reused. To understand the reuse checkbox we can look at a couple examples.
Suppose Many Windows is close to what you want but that you find it annoying that the build results from your last build are lost when you start a new build (because there's only one build window). If you uncheck the Reuse checkbox for the build task, then every time you start a build, a new build window will be created, even if there's already one open from a previous build.
As another example, maybe you like to edit files in a different window, but you don't want each file in its own window. Start with the Many Windows configuration, but check the Reuse checkbox for the editor task. Now, when you double-click a file to edit it, a separate window will be created for the first file, but as you double-click more files, they will all load into that one editor (you can switch between the files using the files popup in the editor's navigation bar.)
Let's look at one more example of customizing your settings in the Expert tab. You like the Many Windows mode for the most part but you're an object-oriented kind of person and you always want to edit files in a window with an attached class browser. Set the editor task to use the Classes template instead. Now, whenever Project Builder needs an editor it will use the template that includes a class browser.
Customizing Templates
What we've covered so far is already pretty flexible. But wait, there's more. What if you don't like the default size of the Targets template? What if you want different items in the toolbar of your build windows? What if you don't want a built-in editor in your batch find window?
We talked a bit about templates in the previous section, explaining how each task can have a different template assigned to it and how Project Builder comes with a set of default templates you can choose from. Well, it turns out that these supplied templates are just a starting point. We think the default set of templates is probably all most people will need, but you can change the default templates or create whole new templates.
One thing that may not be obvious is that all the windows in Project Builder are actually the same kind of window with different configurations. Templates include information about window sizes and positions, the internal setup of the windows (how big the various splits and tabs are, whether the horizontal and vertical tab bars are shown, whether the status bar and toolbar are shown, what items are in the toolbar, etc...) All of these settings are actually individually controllable. If you wanted to, you could start with an editor window and transform it into the old All In One style window with a series of operations. So templates are just bundles of settings that determine how a Project Builder window will look.
The Task Templates Preference pane has a third tab called "Manage Templates" where you can deal with window templates. This tab lists all the templates that are defined. Factory-supplied templates are shown in blue (and cannot be deleted or renamed). From this tab you can create new templates by duplicating an existing template, delete templates you have defined, edit existing templates to change their UI configuration, or rename templates.
When you edit a template, a new window with that template's configuration is run modally. Make whatever changes you want and when you close the window you will be prompted whether you would like to save your changes. Unfortunately, toolbars cannot be customized in this mode, so to customize the toolbar for a template you will need to use Customize Toolbar... from the View menu and make the changes to a real instance of that template window.
The Manage Templates tab also has checkboxes that allow you to enable two advanced View menu submenus (which are turned off by default). The Workspace Templates menu allows you to create a window of any template explicitly at any time and also provides a few commands to edit templates more directly. The Project Content Tabs menu contains commands that allow a sliding tab to be opened or closed in any window whether the tab is visible or not.
Creating Template Windows Explicitly
When one of the defined development tasks is performed, a window is created from the template that is assigned to that task. But, if you turn on the Workspace Templates menu, you can also create a window directly from any defined template by choosing it. Why would you want to do this? Here are some examples:
Suppose that you usually just want one batch find window and that each time you do a batch find, you'll just reuse that same window. Your Task Template preferences would then be set to have the Find task's Reuse checkbox turned on. But let's say that every once in a while you actually need to be able to do two searches and compare the results side-by-side. You could uncheck the Reuse checkbox, but this would mean you'd always get a new batch find window for each batch find which is not really what you usually want. Instead, you can just ask for a new Find template window in the cases where you need more than one. Just choose the Find item from the Workspace Templates menu to get as many batch find windows as you need.
Another time you might want to create a template window directly would be if you have defined a special template that you want to use occasionally but which is not assigned to any task. Sometimes you want to just quickly browse the breakpoints that are set in a project. You might define a template that has the Breakpoints tab showing and a built in editor, but you do not want to assign this template to any specific task since it's not appropriate for any of the tasks. Instead, when you want to browse your breakpoints, just choose the template you defined from the Workspace Templates menu.
Still to Come
While a lot of the features we are planning related to the multi-window support are now in place, there are a number of features and improvements coming. In the interests of heading off requests and bug reports for things we are already planning to address, here's a partial list of some of the features we're still planning to add.
Remembering window positions and selections for editor windows for individual files. The incomplete support that was in previous versions is now gone altogether. The plan is to replace it with a more complete scheme that will work with the new UI.
Extensions to the amount of information about window setups that is currently stored. Project Builder currently remembers a fair amount, including the window size, position, internal split states, what files were open, and more. We will be working to expand that data to include new information (like the expansion state of outlines).
Synchronizing a window's list selection with what's showing in its attached editor.
Window management, window titles, and the Windows menu. Some of this is here now, more will be coming. We are still working on adding better window management support including tiling options, better window titles, better organization of the Windows menu, ways of navigating between windows, etc...
Opening new windows, especially "simple" editor windows is too slow. There are a number of areas that have already been identified that should give us some good improvement here when they are addressed.
Build System
GCC3 Support
This release of the Developer Tools CD includes a pre-release version of the gcc 3.1 compiler. The default compiler is still gcc 2.95, but the default compiler will be switched to gcc 3.1 for the final release of these tools. You can get a head start by testing your projects with the new compiler. Warning: Apple does NOT recommend shipping code produced with the version of gcc 3.1 in this release.
This version of Project Builder has support for the GCC 3 compiler. For any target, you can tell Project Builder to use GCC 3 instead of the default GCC 2.95.2 compiler by setting the USE_GCC3 build setting to YES. You can do this in a Build Style so that your main builds will still use the production 2.95 compiler while still allowing you to do testing of gcc 3.1.
In order to support GCC 3, Project Builder's support for "implicitly included header files" (a.k.a. "prefix files") has been simplified somewhat. While GCC 2.95.2's cpp-precomp preprocessor looks for a corresponding .p file in the same directory for every .h file it finds, GCC 3 will eventually use a single "PFE" (Persistent Front End) file that contains the precompiled information from a single header (and everything that it imports). Currently, gcc3 has support for both the "old' and "new" way of doing precompiled headers. The "old" way is currently still the default, but that will change. The PFE mechanism currently offers about the same performance as the cpp-precomp mechanism for C and Objective-C, but it has two huge advantages: it works for C++ and Objective-C++ too, and there many known tuning opportunities that will eventually let the PFE blow away the older mechanism. We encourage people to try the new PFE support as they try the new compiler. We especially encourage this for C++ developers, who should be able to see huge build time improvements using the new mechanism.
Project Builder's support for an arbitrary set of "implicitly included header files" has been replaced by support for a single implicitly included file (which is now called a "prefix header", as it is in many other IDEs). The single prefix header can optionally be specified to be precompiled, just as before. By default, this means that a .p file will be created for it. If you are using GCC 3, you can optionally specify that a PFE file should be created instead by setting the build setting USE_GCC3_PFE_SUPPORT = YES. Any existing Project Builder projects will automatically be upgraded so that any targets using "implicitly included headers" will instead use the new prefix header feature. Any upgraded target that uses more than one implicitly included header will automatically get additional -include arguments appended to the end of the target's OTHER_CFLAGS build setting. Therefore, all upgraded projects should build exactly as they have in the past. The main difference that users will notice is that the user interface for editing the prefix header under the Build Settings tab in the target editor is now less confusing. Apart from that, the switch to using a single prefix header should not be noticeable.
In the GCC 3 case, when using the new PFE mechanism, a separate PFE file needs to be built for each dialect of C that is used in the target. The valid dialects are currently C, Objective-C, and C++, and Objective-C++. Project Builder tries to figure out which dialects you need, but if you need to you can explicitly specify the set of C dialects for the prefix header by setting the PFE_FILE_C_DIALECTS build setting. This should be a space-separated list of dialects for which to precompile the prefix header (the default value is "c objective-c c++ objective-c++", which means that all four PFE files will be generated). Over time, the GCC 3 compiler will be improved so that at most two PFE files need to be generated (one for C / Objective-C and another for C++ / Objective-C++).
Target, Build Style, and Executable Duplication
It is now possible to duplicate a target, build style, or executable. Before duplicating a target consider what you're trying to accomplish. Many things that might lead you to duplicate targets in other IDEs are better solved with build styles in Project Builder. For example, if you want to duplicate an application target to make a debuggable version, you really should use build styles instead. If you want to duplicate a plugin target because you want to create another plugin that shares many of the same settings as the original, that's a good reason to duplicate a target.
The basic rule to keep in mind is that if your goal is to build essentially the same product in different ways (ie to build your application with debug assertions turned on or off), you should use build styles. If you are building two different things, use targets.
Executables Separate from Targets
In prior versions of Project Builder, executables were per-target. This meant that the active target always dictated what would be run or debugged. This could be annoying in projects that include a lot of frameworks or bundles which cannot be directly run. It often caused people to have to switch active targets between building and debugging or else caused them to create custom executables that were all the same in all their framework and bundle targets.
Now, executables are separate from targets. Each target that builds something that can be executed contributes an executable to the list to represent their product. In addition, users can define custom exectuables. With this new structure, the active executable is now separate from the active target. Whenever you switch targets, if that target has an executable (ie it is a tool or app target), the active executable will be synchronized with the target, but when you change to a target with no executable, the active executable is left alone. (Example: Switch to target MyApp and the MyApp executable will be made active, then switch to target MyFramework, executable does not change.)
To help manage this, executables now have their own vertical tab in the project window (which will probably be going away in favor of merging the targets, build styles, and executables lists into one list in the Targets tab) and their own editors (target editors no longer have an "Executables" tab). In addition, the executable editor's UI has also been improved.
More Java Build Setting UI
The target editor now has simpler UI for setting common Java-related build settings and product settings (previously they could only be set in the expert build settings table). In the Build Settings tab there are two new settings modules: Java Compiler Settings and Java Archive Settings. In the Product Settings tab there's one new module: Cocoa-Java Specific.
The Java Compiler Settings includes control over what compiler to use (currently jikes or javac), enabling or disabling warnings, generating debug symbols, source file encoding, target VM feature set, etc...
The Java Archive Settings includes control over what type of archive to create, its extension, whether it's compressed, etc...
The Cocoa-Java Specific settings includes control over the various NSJava... keys that are used by Cocoa-Java applications.
Build-in-place for Install Builds
There has been a big change in the way install builds are done. Although the support has not been fully pushed through the UI it is now possible to do install builds from the IDE (note: for deployment purposes it is often desirable to do your final builds as the "root" user and, for that, using pbxbuild install from the command line is still the best way to go).
To build for install from the IDE, modify your "Deployment" build style, or create a new build style. In the build style create a new setting DEPLOYMENT_POSTPROCESSING = YES. This build setting will trigger the same build behavior as pbxbuild install (in fact, pbxbuild install now simply causes this setting to be YES.) Install builds should still be considered the last step in a release process. Project Builder does not and will not have direct support for running/debugging the results of an install build. Install builds are for producing final product layout, not for development. By default, Project Builder will construct a root in "/tmp/<ProjName>.dst" (you can change this by specifying a setting for DSTROOT in the build style you're using for install builds). We do not recommend doing install builds directly into the root file system of your machine (DSTROOT=/) which can be dangerous, especially for projects that build important frameworks. Instead we recommend building to a side folder and then, after verifying that the build looks good, using a tool like ditto (eg. "ditto /tmp/myproj.dst /") to install onto your system or using the root to produce a disk image or installer package.
There has been a lot of underlying change to support this and to clear up a number of other limitations with the build system generally and install builds in particular. Following are some technical details that may not be of interest to those not deeply familiar with aspects of Project Builder's build system.
Install builds now construct the products directly in their install locations (in the DSTROOT) instead of creating them in SYMROOT and then copying them where they need to go. Some of the advantages this provides include better support for installing extra stuff for non-bundled targets more easily (eg headers for library targets), making it possible to support install builds from the IDE (more direct support for this is still coming).
Possibly, projects that were doing somewhat advanced things may have to change. If your project referred to the value of SYMROOT in the context of other build settings or in shell script build phases, those references need to be changed to either TARGET_BUILD_DIR or BUILT_PRODUCTS_DIR. Use TARGET_BUILD_DIR if you were using SYMROOT to locate the product that your target constructs. TARGET_BUILD_DIR will evaluate to the Build Products Folder during normal builds and to the target's Install Path within the DSTROOT during install builds. Use BUILT_PRODUCTS_DIR if you need a location that contains the products built by other targets in your project.
In some cases build processes may rely on artifacts of the traditional build process. If INSTALLED_PRODUCT_ASIDES is set to YES then the ASIDE_DIR, which is by default the BUILD_DIR, receives copies of built products before they are prepared for deployment. This option is useful to insure that build results include unstripped binaries that can be used for debugging in addition to the stripped binaries. By default the installed product asides feature is off.
Build Variant Support
It is now possible for targets (primarily frameworks) to build special variants of themselves for profiling and debugging. This feature is meant not for development of the actual framework but rather to enable the developers of a framework to supply profiling and debugging support to the clients of the framework. For example, the CoreFoundation framework on Mac OS X actually has three binaries inside it: CoreFoundation, CoreFoundation_profile, and CoreFoundation_debug. All these "variants" are packaged inside the same framework wrapper. The profile variant can be used by developers trying to profile their applications to get profiling data that includes the CoreFoundation framework's code. The debug variant includes extra assertions and other error checking code that developers can use to help track down problems in the way they use the library. Note that the debug version of CoreFoundation does not include full debugging symbols such as the developers who actually work on CoreFoundation might need.
You can build these additional variants now with Project Builder simply by setting the BUILD_VARIANTS build setting. By default, the value of this setting is "normal". You can build all three variants by setting it to "normal profile debug". If you need to pass special compiler flags for one of the variants, there are some special settings you can use. Currently, the only supported per-variant flags are cc_normal_FLAGS, cc_profile_FLAGS, and cc_debug_FLAGS. There will likely be other variant-specific settings possible in future versions. Be sure to tell us if you have a need for one that is not available in this version.
For development purposes you may want to have only the "normal" variant and set up a build style to build the extra variants only when building for deployment. Remember that building three variants will take almost three times as long as building one.
C++ Code Builds with the "c++" Front End
In previous versions, the build system used "cc" to build all types of C code. It now will use the "c++" front end to build C++ and Objective-C++ source code. If a target contains at least one source file that will be processed with "c++" then the final linking is also done with "c++". The "c++" front end has different implicit behaviors including automatically linking libstdc++.a and automatically locating standard C++ header files.
Handling of Resource Manager resources (.r and .rsrc files)
In previous releases all resource manager resource building was done in append mode, and the results went directly to the final location for the resources. This approach caused a number of problems including but not limited to append mode silently dropping resources that conflicted, resources having to be entirely rebuilt if the final location was rebuilt, and protected resources causing rebuilds to fail.
Resource Manager Resource build support has been substantially changed for this release. Now, the first resource that is built does not use append mode, and resources in conflict cause explicit build failures. Additionally, resource manager resources no longer go directly to their final location, but instead go to a collector which, after all resource manager resources have been compiled, is then used to copy the compiled and collected resources and added to the collector these resources are put in their final location using ResMerger. Because of the collector it should no longer be necessary to rebuild all resource manager resources when their final location is removed or refreshed, and protected resources should not block rebuilds.
Other Improvements
Several improvements in jikes support have been made using new features available in the updated jikes we now have. (This release includes jikes 1.15.)
Warnings and errors from building precomps of prefix headers are now caught and shown in the error and warning list.
The logic for doing build setting variable expansion has been reworked and drastically improved. Mostly this provides us with a much better base for future work. One immediate benefit is that far fewer build settings are treated specially in any way. For example, it should now be possible to define settings like SYMROOT and OBJROOT in a target or build style (it is a fairly advanced thing to need to do this...)
There is now an additional option for the build location in the project inspector panel: Place intermediate files for this project in the default location. This allows per-project control of the product location, while still placing all the intermediates in a common, project-independent location.
There is now per-file control of whether MiG should generate client or server stubs for .mig and .defs files. Previously this could only be controlled on a per-target basis, by setting the MACH_SERVER or MACH_CLIENT_AND_SERVER build setting to YES. Project Builder now has checkboxes in the target file list for .mig and .defs files. Project Builder will upgrade projects that contain the old MACH_SERVER and MACH_CLIENT_AND_SERVER to instead use the per-file attributes.
We have added initial support for improved header dependency analysis better. By default, the behavior is the same as before. To try out the new stuff, set INDEX_BASED_HEADER_DEPENDENCIES to YES in the Build Settings of your target or in a build style. This will cause Project Builder to use a project's index to explicitly generate header dependency information for builds instead of relying on our underlying build tool to grep through source files for #include lines trying to match them up with files. In theory this will give us complete and accurate header dependency modeling. Please give this a try with your project if you have had trouble with incomplete incremental builds when you edit header files. The goal is to eventually make this the default.
pbxbuild has a new -optionalbuildstyle argument that will use the specified build style if it exists and will just silently not use it if it does not exist.
Debugging
NSString Contents in the Variable List
When debugging a Cocoa application, the variable list will now show the contents of any NSString variables. Also, there's now an extra column in the list. The new "Summary" column shows the actual contents of the string. The original "Value" column still shows the address of the string. This feature is actually just the beginning of support for much better handling of opaque types and objects in the variable list.
Runtime Type Column in Variable List
There's an optional new column that you can insert into the variable list which shows the static type of variables. The display of this column is controlled by the "Show Types" menu item in the Debug menu. Currently, whether this column is visible is not remembered across sessions, so you'll need to insert it with the menu each time you need it.
For NStrings, the type shown is the dynamic type of the object. We hope to show more dynamic type information in future releases.
Java Debugger
Print Description to Console (the context menu command available in the variable list pane of the debugger) now works for Java debugging as well. It invokes toString() on the selected object and prints the result.
Hardware watchpoints in gdb
GDB now supports hardware watchpoints, with a few limitations. Currently this feature is only available through the gdb console, but we call it out here because this is a feature which can save an enormous amount of time when debugging certain kinds of problems. Please see the gdb release notes for more details.
File Editing, Searching, Class Browsing, and Documentation Integration
New File Typing Mechanism and Preferences
Project Builder now has its own file typing system. It defines a hierarchy of types instead of a flat list (so that "TIFF" can inherit from "image" and "html" can inherit from "text", etc...) It can recognize the type of a file from its extension, from its OSType (actually, not yet), or from arbitrary "recognizers" that can examine the path more closely or even look inside the file. The new mechanism can also distinguish binary files from text if attempts at more specifically recognizing a file fail.
Over time this mechanism will be used more and more throughout Project Builder. Currently it is mainly used for mapping files to appropriate editors. Just this use has helped us to solve a number of thorny problems in previous releases: binary files will no longer ever open in a text editor unless specifically requested by the user, binary files will never be searched during batch text or regex finds, when there are multiple internal editors that could edit a file it is now possible to set which to use by default and to open a given file in one of the non-default ones as a one-time operation.
There's a new Preferences pane called File Types which allows setting which available internal editor is used for each known file type. The pane contains an outline of the known file types and each row has a popup to select which editor to use.
The Files tab and the Bookmarks tab now have "Open As..." context menu submenus that allow choosing a specific editor to open a given file with as a one-time operation.
Using this new mechanism we now are able to distinguish HTML documentation from other HTML much more robustly and you may notice this as changes in what HTML files show up as plain text vs. rendered. Of course, you now also have independent control through the preferences panel for which editor type will be used for documentation and other HTML.
Java Indexing Changes
The list of Java files to index now includes all source files in a project. Previously, this list was based on which target was active when a project was opened. This now allows Java projects that use an external build system via a legacy makefile target (e.g. "ant") to be fully indexed.
Jar files and folder references added to a project are indexed by default. This can be turned off by selecting the Project->Show Info menu item and unchecking the "Include in index" checkbox. Jar files produced by a target are no longer indexed by default. This fixes a common case where multiple entries for a class would appear in the class browser.
Other Improvements
Regular expression searches now respect the Ignore Case setting.
The progress indicator for batch finds is now more accurate. We now preflight a batch find to provide this accuracy which means a slight delay before the searching starts. This delay is most noticeable the first time you do a search and can be several seconds for large projects. But once the project's caches are heated up, it generally takes less than a second to preflight even in large projects.
The class browser now shows Java classes with class name first followed by the package name, if any. Also, Objective-C categories now show more reasonably in the Command-Double-Click popup menu.
It is now possible to open a file from a build phase's file list by double-clicking it.
There are a couple new commands in the Format menu that allow syntax checking of property list files.
Project Builder no longer opens the Release Notes in each new editor. Instead it opens them in a separate window once for each time you upgrade to a new Project Builder version.
Edited (unsaved) files now show with a grayed out icon in the group tree as well as in the loaded files popup.
We now use the display name of a document in the navigation bar and window titles. This makes little difference except that we also now use the HTML documents <title> as the display name for documentation which should make things a bit more sensible.
Added typename to list of C++ keywords for syntax coloring.
/**/ is no longer misinterpreted as an unterminated javadoc comment for Java syntax coloring.
Various bug fixes and improvements to function popup scanner for C++ (default args, operator overloads, throws clauses).
Various bug fixes and improvements to function popup scanner for Java (abstract and native declarations).
Several bugs were fixed in documentation lookup logic that should allow more language constructs and Carbon API to be mapped to its documentation correctly. (A number of known bugs with broken documentation lookup still exist.)
The loaded files popup in the nav bar of Project Builder's editors has changed. It now shows only open files that have actually been viewed in the window containing the editor. All split editors in the same window have the same contents. This has implications for which files will be closed when closing a window or a split. Closing a split will no longer ever close any files. Closing a window will close all files that are listed in the loaded files popup(s) in that window that are not also listed in the loaded files popup of another (still open) window. If you use the many windows mode, this should generally translate to the behavior where closing a window will close the file shown in it.
Split editors are now saved and restored as part of the content state of a window. In addition, the current bookmark, loaded files bookmarks and history bookmarks of each editor are now saved and restored.
The "Whole Words" checkbox in the simple and batch find UI has been changed to a popup with three choices: "Contains", "Starts with", and "Whole words".
The "Open man page" panel (in the Help menu) lets you look up UNIX manual pages by command name. Unless you specify the section of the manual, only section one is searched. However, you can specify the section using any of these formats as input: "man 2 chmod", "2 chmod", or "chmod(2)". In addition, the "Open man page" panel lets you search the UNIX manual by keyword lookup (similar to the 'man -k' or apropos commands). This searches through the title strings of man pages in all sections and presents a list of matches.
In the class browser, Protocols/Interfaces now show up in a sub-group rather than at the top level of the outline. The class browser options now allows you to choose whether to show Protocols and Interfaces. It also now allows you to control how Obj-C categories are displayed.
.html and .wod files now act as counterparts. The counterpart button in the nav bar of editors will flip between files with these extensions if possible.
The documentation viewing plugin now displays status messages for lengthy operations and in some cases error conditions (such as when you click a broken link).
There are several new menu items in the Find menu. There's a Find Selected Text which is the same as choosing Use Selection For Find and then Find Next (this command is often bound to Cmd-H in OS 9 editors). There are also new Replace, Replace and Find Next, and Replace All menu commands. None of the new commands have key equivalents by default, but the items now exist so experts can add key equivalents for them using the NSUserKeyEquivalents default. (Choose "Show Expert Preferences Notes" in Project Builder's Help menu for more details.)
The context menu for the Files tab and the Bookmarks tab has new items that allow you to open a file with Finder instead of using any built-in editors and to reveal a file in Finder.
The Documentation Viewer supports arrow keys for scrolling and pressing space as a synonym for Page Down.
The Documentation Viewer supports a default to specify the font size to use as the "base size" for HTML display. Currently this is only settable as a command-line default: DVBaseFontSize (see the Expert Preferences Notes from the Help menu for more details).
Note that there is a known issue with the class browser that can occur in some circumstances which can cause long delays in saving files. If this happens to you, the workaround is to switch to another tab so the class browser is not visible.
Miscellaneous Improvements
General Preferences Pane
The General preferences pane has been revised. Several options that made no sense with the new multi-window UI work have been removed. Some new ones have been added. You can now control whether PB saves state about your open windows, their configurations and their open files (default is to save state, but if you turn this off, you will get a fresh Project Task window when you open a project). You can control when a project closes: either when the last Project Task window closes (the default), or when the last window for that project closes. You can control what happens when you double-click in a class browser (really only useful in Many Windows mode): either it will open an Editor Task window or another Browser Task window. You can control whether the "counterpart" button (the one that switches between a header and its implementation file) will obey your multi-window preferences or always replace the content of the editor where it was clicked.
Other Improvements
The Add to Bookmarks command now works in many more contexts. You can now use it to create a bookmark from the group tree, the class browser, find results, build errors/warnings, the target list, the build style list, build phase file lists, etc...
Reveal in Group Tree now works for the current selection in the bookmarks tab, the classes tab, the find results, the build errors/warnings, build phase file lists, etc...
There are new context menus for the bookmarks tab, find results list, and build errors/warnings list. The context menu for the code editor has been redone to include some more useful commands. There are some new items in the group tree context menu. Project Builder now has a Dock menu containing a few global commands
Rows can be copied/dragged from the CVS revision table in the Info panel (dragging drags a text clipping of the row, copy copies the text). The table also now supports simple sorting based on any single column. The sorting of revisions has been improved.
There's a new tool in /Developer/Tools called pbprojectdump. This tool takes a pbproj and outputs a more nested version of the project structure (Project Builder does not nest objects in its file format to cut down on massive project diffs from moving files around in the project, but this makes the files harder to interpret by humans). This tool is now used by FileMerge when FileMerge compares project files and should result in more sensible looking ways of viewing project diffs. Note: due to how conflicts are represented in project files, pbprojectdump cannot compare project files with CVS conflicts.
The Assistant UI has been tweaked a bit. The main difference is that there's no longer separate Next and Finish buttons (the one button's title now changes to reflect whether you're going to the next page or finishing.).
CVS support now uses a default to know what tool to invoke. PBXCVSToolPath can be set to the path to the cvs binary to invoke. The default is /usr/bin/cvs.
There are quite a few new toolbar items available, some of which appear in the default toolbars of various of the predefined workspace templates and others of which can be added by customizing your toolbar(s).
The Info dialog now shows the Project Info if there's nothing more specific to show. Before you had to select the top item in the group tree to see this Info pane.
There's now a +YEAR; macro that can be used in file templates (and source files of a project template). It is replaced by the current year. Existing file templates have been updated to use it.
There has been quite a bit of change in Project Builder's menu structure.
Project Builder will now remember the order and widths of table and outline column headers for tables and outlines that have re-orderable or resizable columns.
The data displayed in the SCM inspector pane has been tweaked and improved.
Notable Bug Fixes
Command-Double-Click will now fall back on a "contains" search if a "starts with" search turns up no results. This should improve handling of Java class names when the classes are in packages.
Fixed a bug where some project changes might not get written when Project Builder deactivates (Project Builder always saves any pending project changes when the app deactivates in case you're going to Terminal to start a pbxbuild or something...).
Batch Definition searches no longer try to weed out results based on the Project files/Framework files settings in your find options. This adherence to the settings always caused more confusion than benefit.
When creating a new file, if multiple files will be produced and two or more wind up having the same name, only one will be created.
The assistant dialog now remembers its size between uses.
Fixed a bug with Cut/Copy/Paste support in some of our tables.
The low-level build system now correctly recognizes ".c++" as a C++ file extension.
Fixed a problem where breakpoints on Java inner classes were not working.
A potential crasher that could occur if you closed a window less than half a second after clicking a file in one of our lists was fixed.
The counterpart button (the button in the navigation bar of an editor that flips between header and implementation files) now prefers files in the same folder as the original file in case you have multiple files of the same name in the project. Open Quickly has been similarly changed to prefer the folder where the current file lives (if any).
The labels of buttons in various open or save dialogs has been changed to be more appropriate. Also, a New Folder button has been added to various Save dialogs.
Replace All will now replace throughout the whole file if Selection scope is chosen but the selection is zero-length.
The "Shared Support" popup choice in Copy Files build phases did not work for target types other than Framework, now it does.
When syntax aware indenting is turned on, but the current file is not indentable, tab and return now have their previous behavior (tabbing in leading whitespace indents one indent width and return will indent the new line to the same level as the previous line.).
When syntax aware indenting is turned on, pasting will now indent even when the pasted text is only a single line (as long as the pasted text includes at least one line break).
A bug that could cause the "Also create ..." checkbox to appear when it should not in the New File assistant has been fixed.
The Bundle target template no longer contains a -undefined suppress linker option.
Several fixes have been made to the parsing of specific linker and compiler errors and warnings.
Several project and file templates that did not work if they had spaces in their names were fixed.
When the debugger stops with a very deep stack, the responsiveness of Project Builder has been improved by having the frames fetched in chunks from gdb instead of all at once.
Various nibs have been updated to improve Aqua guideline compliance.
The logic for figuring out what breakpoints in open projects are relevant for a particular debug session has been reworked to be more accurate.
A large number of small leaks have been found and plugged.
There was a bug in the Text Editing Preferences pane that could cause bad prefs values to be written which would then cause the Preferences panel not to be able to be brought back.
_______________________________________________
projectbuilder-users mailing list | projectbuilder-users@lists.apple.com
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/l...tbuilder-users
Do not post admin requests to the list. They will be ignored.
Top
