Out of Source Builds

[BCSharp]

The current SCons build is an in-source build, meaning that after a build, intermediate and final build artifacts are intermingled with source files. Apart from aesthetics, it is undesirable for several reasons:

• It pollutes the file explorer (or equivalent) tree view making is unnecessary long and more cumbersome to navigate.
• There is no simple way of cleaning those artifacts scattered around. One way is git clean -dfx. That is the nuclear option that will delete also files that are in the work area that may be wip and should be preserved. Another way is to run scons --clean. This one has some limitations, though:
  • It assumes that SConstruct is in a working state; this may not be so in the middle of development.
  • scons -c has to be run with the same option as the existing build was run. For instance to clean after scons mode=debug, one has to remember to run scons mode=debug -c.
  • Currently it does not delete all intermediate artifacts. For instance it knows nothing about artifacts produced by other sub-build systems, like dotnet build.
  • Since SConstruct changes between commits, the working area should be cleaned with the same commit checked out as when it was built. Pulling new commits into a dirty working area and then trying to clean may leave files behind. The same when switching branches, checking out past revisions, etc.
  • There is no equivalent of purge, that is deleting all and only build-time-created artifacts unconditionally.
• Perhaps most importantly, by definition, it can hold only one build configuration at the time. That is, it is either release or debug, net462 or net6.0 etc. It is not possible to test them out in parallel. Switching back and forth between them requires the aforementioned working area cleaning, which is already problematic and requires the complete rebuild of everything at every switch.

A solution I would like to go ahead with is to use out-of-source builds, like in IronPython. All build artifacts, be it intermediate or final, would go into separate directories that are not under source control. SCons has some provisions for out-of-source builds with its variant dir mechanism, which works somewhat different that msbuild or CMake, but there is no point to fight the tool so I intend to use it.

As the first step of separating the source files from the build artifacts, I have moved __init__.py from build/ironclad into data with a rename. So @slozier, if you need to edit this file, be aware that any edits need to go into data/ironclad__init__.py and that any changes directly in build/ironclad/__init__.py will be overwritten by the next build.

[BCSharp]

Another breaking change alert

The recent commit carries support of builds targeting .NET 6.0 (out-of-source build only). Consequently, to test those builds, the Dockerfile is updated to install ipy on .NET via dotnet tool. So now, in new containers, there will be two ipy.exe on the search path. As it happens, the one for .NET wins over .NET Framework. Tho make the latter easily accessible, I have added a symlink ipyfmwk that always launches the Chocolatey install.

This change does not affect the SCons scripts because they use absolute paths to locate appropriate executables, but for if you want to ipy manually in the container (e.g. ipy runtest.py), you need to use ipyfmwk command to get the one running on .NET Framework.

[BCSharp]

Final update (w/ breaking changes)

In commit ffdead2 I renamed the SCons scripts so that the out-of-source build is the default. The breaking change is that after a regular build using scons, the final build artifacts (Python package ironclad) are placed in directory out/«configuration»/«framework», rather than build. So any external test environments need to be updated accordingly.

I deliberately kept the in-source build option functional, to be run through scons -f main.scons .... This is mainly as a reference point in case something doesn't work as expected. In-source builds are less convenient but easier to get right, especially given the Ironclad's legacy. There are still some remnants of the in-source fixed build paths in test scripts that are currently not being run, but which we will want to enable at some point. If the out-of-source test fails but the in-source passes, it will be clear where to look.