If you have upgraded some trees in a forest and not others, you may have build trees that are fully upgraded except that they still contain external-dirs keys in their Abuild.conf files. If this happens, when you run abuild, you will get a warning that tells you that you should run abuild --upgrade-trees. However, if you try to run the upgrade process from the root of that tree, it will tell you that there is nothing to upgrade. The solution is to run the upgrade process from a directory that is above all the externals that are still there. Once the externals are upgraded, then abuild will be able to replace the remaining external-dirs keys with tree-deps.

In abuild 1.0, if you have a collection of trees that refer to each other through their external-dirs keys, in the context of any tree, abuild only knows about items that are reachable from that tree. In abuild 1.1, abuild knows about all items that are reachable from any tree in the forest. For example, if you have trees A and B that both refer to C but don't refer to each other, in abuild 1.0, A and B could have build items with the same name. This would work because abuild would never know about A and B at the same time. If you came along later and make build tree D refer to both A and B, you would get an error message at that time since abuild would complain about seeing the same item in multiple locations. In abuild 1.1, abuild would know about all three trees and would immediately complain that A and B both contained an item with the same name. So it's possible that, after running the upgrade process, you may need to rename some build items. If you have been careful to stick to build item naming conventions that avoid duplications across tree boundaries, you should not run into this problem. During alpha testing of abuild 1.1, at least one case was encountered in which a build item had been copied from one tree to an unrelated tree without changing its name. Abuild was able to upgrade the all the trees and complained about the problem after the upgrade was finished.

When abuild 1.1 encounters a build item with neither a tree-name key nor a parent-dir key, and if that build item is not referenced as a child of the next higher build item, abuild can't tell whether it is the root of a non-yet-upgraded build tree or whether it just hasn't been properly added to its parent's Abuild.conf as a child. In 1.0-compatibility mode, abuild will guess that it's missing from its parents Abuild.conf if there is a name key. Otherwise, it will guess that it is the root of a forest. In 1.1-compatibility mode, abuild will issue an error. If you are running in 1.0-compatibility mode on upgraded trees and you get unexplained errors about build items not being known, you might first try running in 1.1-compatibility mode where you might get a better error message. If you have intentionally left it out of the parent's Abuild.conf file because you want to disable the build item for some reason, then you must either enter this directory in the ignored directories section of the abuild.upgrade-data file or add it back as a child of its parent during the upgrade process and remove it again later.

In the make backend, compiler toolchain implementation files are now loaded before Abuild.mk. Most of the time, this won't matter, but sometimes it might, particularly in the case of errors in Abuild.mk that may have not mattered before. For example, a Abuild.mk file may check to see whether a variable is defined or not and take some action based on that. If the variable in question is defined by a toolchain support file, it could change the semantics of such a check. At least one case was found during testing in which a Abuild.mk file assigned to XCPPFLAGS using “:=” in Abuild.mk thus overwriting values supplied by the interface system. Additional values supplied by the toolchain support file in turn modified the value as supplied by the user's Abuild.mk, which allowed the incorrect assignment to go unnoticed. With the 1.1 load ordering change, the error in Abuild.mk suddenly caused the build to stop working.

Again, in the vast majority of cases, Abuild.mk files should not need to be changed as a result of this ordering change, but if your Abuild.mk is inspecting or modifying variables that are also used by the toolchain support files, you may see a slight change in semantics.