Since you haven’t gotten around to this, I’ll take a stab at it. Looks like it’s now based on the “output-directory” config option. There’s one of these for each target, which you can override using <config:target output-directory="custom/path". Make sure to put this below <haxelib name="openfl" />. (The custom path is within the Export directory. If you want to change that directory, just set <app path="Custom/Export/Directory" /> as usual.)
Personally, I’ll definitely use this. I have disk space to spare, and it saves a lot of time for C++ builds. Plus, it will help me avoid template cross-contamination. (I don’t always remember to clean my templates.)
Using <config:(target) output-directory="" /> it is possible to make the output folders much more nuanced than the old defaults. In my tests, HXCPP does not clobber its cache when changing between debug or release builds. Similarly, iOS builds no longer affect the build cache when changing build configurations. Many projects may not need to distinguish between build configuration types (because this is not required for build performance), but for projects that do want to distinguish, there might be other factors in the separation of builds.
- windows
- windows-neko-release
- windows-neko-release-qa-steam
Etcetera 
Here are some of the defines that may be helpful:
- ${platform} – the name of the target platform (“flash”, “windows”, etc)
- ${buildType} – the name of the build configuration (“debug”, “release”, “final”)
- ${targetType} – the technology used (“cpp”, “neko”, etc)
…but you can your use your own defines as well
<define name="how-awesome" value="super-awesome" />
<config:windows output-directory="windows-${buildType}-${how-awesome} />
Slashes are also supported in output-directory if you would prefer to use subdirectories, but parallel “dashed” directories may feel cleaner
2 Likes
