In building CodeBlocks, I'm wondering why .a files end up in src\output31_64?

[everSome]

Any particular reason why src\update.bat copies archive (i.e., .a) files to src\output31_64?
The command doing this is:

echo Transferring LIB files from devel to output folder
xcopy "%CB_DEVEL_DIR%\*.a" "%CB_OUTPUT_DIR%" /D /y > nul

As you can see, I'm building CodeBlocks on a windows machine,
I'm letting xcopy commands fall through to windows, which wants it's options
at the end of the command rather than at the beginning, but that's nether here nor there, I'm guessing.

[Miguel Gimenez]

One developer decide to copy libraries so plugin writers could link with them. You can delete all .a files if they bother you.

[ollydbg]

Yes, I think the .a library files are mainly for developers who just want to build some new plugins for the current release. They don't need to rebuild the C::B. They just need to choose the same compiler as the one used for the release.

[everSome]

Thanks for the quick answers. I'm new to CodeBlocks and wasn't quite sure what various plugins do. I'll just nuke the copying of that on my system. As a follow up, how does one control the operation of the $TO_NATIVE_PATH{} path conversion function? On windows I suppose it works like $TO_WINDOWS_PATH{}, but I'd like to make it work like $TO_UNIX_PATH{} to support MSYS2 on windows. Using $TO_UNIX_PATH{} works just file, but makes such a change specific to MSYS2 environments, which is what I'm considering staying away from.