Potential problems with outputting to source folder

[daveaglick]

I had originally thought that we could just output generated files to the source directory for the new SDK-style projects and they'd get picked up by the default globbing patterns and wildcard includes. That's probably not going to work though.

The default globs are evaluated before any targets are run so they'll initially contain only what was on disk before the code generator is run. On the first build before the generator has a chance to fire, the output won't be on disk - this may or may not cause a build failure, but the generated output files won't be included in the compilation regardless. On subsequent builds, any changes to the files may result in other problems. For example, deleting a generated output that's no longer relevant will crash the build because the default wildcard glob evaluated it to be there before the generator deleted it.

A couple options:

• Continue to add generated output files to the compilation. This solves the problem of generated files not being included but will still break if the generator needs to delete a stale output file.
• Output generated files to the "obj" folder by default and continue to include them in the compilation. This is the recommended approach for code generation. The downside is they won't be visible (but maybe that's fine anyway).

[CZEMacLeod]

I would go with outputting files to 'obj' by default then including them manually. That being said I use scripty to update an embedded resource file and a resx (depending on various criteria) but they are checked into source control and exist on each build cycle regardless.
Perhaps the build task could track removed files and remove them from the compilation inputs? And indeed call update for existing files so that they trigger incremental build as required?
I had a lot of problems in this area with some of my own build tools.