[Abscissa]

If I do a release build on a file and then try to do a debug build (or vice versa) then build thinks that the program is already up-to-date and won't build the new version. This also happens when I add/change/remove a version parameter. I think this is because it sees that the object files and output file exist and that the source files haven't changed.

Since debug/release/version() can all cause different parts of the code to be either compiled or omitted, using a different debug/release/version() setting should prompt a recompile of any affected source.

This is a problem in one of my projects, since I have to make sure to delete the object files anytime I build something different or else I get strange effects from the wrong versions of various object files being linked together. I know I could workaround this by using the -cleanup flag every time I compile, but that would be somewhat of a kludge and present its own drawbacks.

I think build should automatically recompile when using a different debug/release/version(). Although later on, it might be nice if build could handle this the way A-A-P does, by placing all intermediate files in a separate subdirectory, with the subdirectory's name being based on the build options like "build-nt-debug", "build-nt-release-console", "build-linux-debug-gtk", etc. (http://www.a-a-p.org/exec/tutor-variant.html)

[Derek Parnell]

I understand the issue, and I've been thinking about this earlier. I'm not yet decided on what to do about it yet. In the meantime, you can do either or both these ..

The -full switch to force everything to get recompiled.

The -T<name> switch to give an alternate name to the build target. Eg.

build myapp -Tdebugapp

build myapp -Tfinalapp -nounittest -release
_________________
--
Derek
skype name: derek.j.parnell