msbuild TinyCLR / TinyBooter error

[Nathan-Stohs]

Building TinyBooter and then building TinyCLR will result in incorrect binaries for TinyCLR due to unexpected re-use of libraries.

Work-around: Always do a cleanbuild.

Fix: I suspect that #ifdef SAM_APP_TINYBOOTER is the problem. This is something we use in a few places to determine which project is being built (TinyCLR or TinyBooter). It makes sense that we can't do this because the build script doesn't really have a way to know about lower-level hacks like this, and so cannot invalidate and so reuses the library. Any such code will need to be moved to a different project specific to that build, or we revert to the Am_I_TinyBooter() hack which doesn't involve the pre-processor (it introspects its memory region and determines what it is (TinyCLR or TinyBooter) at runtime).

[AnanthAtSamraksh]

Work-around: Always do a cleanbuild

I don't think a cleanbuild will also help. Retaining SAM_APP_TINYBOOTER while building TinyCLR will cause any module that uses VT to fail (as shown in lines below taken from tinyhal.cpp).

#ifndef SAM_APP_TINYBOOTER // TinyBooter uses SimpleTimer
    VirtTimer_Initialize();
#endif

[Nathan-Stohs]

It is not retained in a clean build.

[MichaelAtSamraksh]

One approach would be to find libraries that use the SAM_APP_TINYBOOTER preprocessor symbol and update their dotnetmf.proj file to require clean before build. However, I was not able to get this decentralized approach to work with msbuild.

Another approach would be to add a special target that cleans all bad libraries, and require this centralized cleanup as a prebuild step to both tinybooter.proj and tinyclr.proj. I haven't tried this, but it would be similar steps to what was required to stamp the software ID into a header file before each build.

[ChrisAtSamraksh]

Well short term I checked in a change to the TestSystem that always cleans tinybooter and tinyclr (no more incremental builds for now).

This seems to fix the problem I was having with sleep.

[Nathan-Stohs]

One approach would be to find libraries that use the SAM_APP_TINYBOOTER preprocessor symbol and update their dotnetmf.proj file to require clean before build. However, I was not able to get this decentralized approach to work with msbuild.

Another approach would be to add a special target that cleans all bad libraries, and require this centralized cleanup as a prebuild step to both tinybooter.proj and tinyclr.proj. I haven't tried this, but it would be similar steps to what was required to stamp the software ID into a header file before each build.

IMO, too arcane to be worth it. Such options above do fix the build but add too much to the burden of knowledge needed by developers of our code and doesn't really buy us anything.

If we can't do something really simple, lets separate the projects or do Am_I_TinyBooter(). Note that I was initially motivated to replace that function with the ifdefs, so this is my fault and this is a retreat, not a "we should have done it my way all along" deal.

[MichaelAtSamraksh]

I think that moving the preprocessor definitions into a header file will work. A pre-build script will populate the header file and modify the header file only when the pre-build script is passed different values for the header file. I hope that this will allow msbuild to always detect changes, and also allow msbuild to only rebuild when the header file changes. However I anticipate that rebuilds could be much longer than a pre-build script that just detects a change and deletes the 1 or 2 libraries that reference SAM_APP_TINYBOOTER/SAM_APP_TINYCLR.

[AnanthAtSamraksh]

Can we consider something similar to the BitBake system used in the Yocto project? This would involve writing a build system on top of MSBuild, but this would help in building for different platforms. http://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#history-and-goals