I use the 'boards.txt' option to run a post-build macro for over-the-air (OTA) programming of a Teensy 3.5.  The macro connects to the Teensy over an RF serial connection, and sends the .hex file to a updater routine running on the Teensy.  To make this work, the macro expects the .HEX file to be located in the 'C:\Users\Frank\Documents\Arduino\WallE3_AnomalyRecovery_V2\Release' folder.  

This has worked well for me for the last year or so, but it started failing when I tried it on a newly-created project, using VM 2.2022.1128-4.  Now the .HEX file appears in the 'C:\Users\Frank\Documents\Arduino\DistanceReportingProb_V1\obj\ARM\Release' folder.  

Before I start editing my macro to point to the new location, I'm wondering if the above change is something to do with the update, or some screw-up on my part.  Looking at the Configuration manager for the 'release' configuration, I see the platform has changed from 'x86' to 'ARM' and I can see in the verbose compile output that the 'new' configuration does indeed put release files in the .\obj\ARM\Release' folder. 

Am I doing something wrong here, or is this the way it is supposed to be going forward?

I ran out of attachment space, so I sent the verbose compile output via email, with a link to this post.

I manually copied the 'obj' file and renamed it to 'bin'.  Now my over-the-air (OTA) post-compile macro works fine. So, it appears that VM has a problem somewhere - either it should be saving the 'release' output to 'bin' or the build property should refer to 'obj' rather than 'bin'.

Thanks for the explanation, but I think all it did was make my headache worse 

I have attached screenshots of the 'old' and 'new' configuration setup.  As you can see, the default (I almost never change the defaults - I'm too dumb too figure out what is better or worse, and my memory is too bad to remember what I did six hours ago, let alone six months/years!) configuration path in the  projects before this latest upgrade 

'output' =  $(SolutionDir)$(Configuration)\ 
'intermediate' = $(Configuration)\

But in the new setup, I see

'output' =  $(ProjectDir)bin\$(Platform)\$(Configuration)\
'intermediate' = $(ProjectDir)obj\$(Platform)\$(Configuration)\

OK, so I see there is a anceReportingProb_V1\obj\ARM\Release\' in the verbose compile build properties output, so I guess I can change my 'boards.txt' file to use it instead of 'vm.runtime.build.final_output_path' as the controlling parameter for my macro file.

In the verbose output from the new project I see:

	Line  554: nceReportingProb_V1\obj\ARM\Release\
	Line  555: vm.runtime.build.intermediate_output_enabled=false
	Line 1180: # Copy build result to 'Project>Property Pages>Intermediate Directory' 

and in the old project I see:

	Line  555: 	Line  555: 3_AnomalyRecovery_V2\Release\
	Line  556: vm.runtime.build.intermediate_output_enabled=false
	Line 1379: # Copy build result to 'Project>Property Pages>Intermediate Directory'=C:\Users\Frank\Documents\Arduino\WallE3_AnomalyRecovery_V2\Release\
	Line  556: vm.runtime.build.intermediate_output_enabled=false
	Line 1379: # Copy build result to 'Project>Property Pages>Intermediate Directory' 

Interestingly, both these sets show that the copy to intermediate option is 'disabled', even though the file copy is happening in both cases - ????

However, it does look like the 'vm.runtime.build.intermediate_output_path' build output parameter does point to the proper place in both the new and old setups:

old configuration: C:\Users\Frank\Documents\Arduino\WallE3_AnomalyRecovery_V2\Release\' compiler output
new configuration: C:\Users\Frank\Documents\Arduino\DistanceReportingProb_V1\obj\ARM\Release\


Yep - worked fine on new project, and on an older project, using the same 'boards.txt' file for both - YAY!!