Hi-Tech Software bought by Microchip - no more other compilers

While I agree that it's bad that project files and files on the disk are forcibly tied, I believe that if a file is not part of a projects source code, it should not be in the source code directory! If a file is not part of your current program, don't keep it mixed up with the rest of the program. For my development work, I always compile using a makefile that compiles all .c files in the directory. For me, "project management" is simply file management.

When you take about a directory of files with one function per file, it sounds to me like a library. If that's the case, then just build it as a library - when you link to that library, only required functions will be included in the executable.

Finally, although I have never used the MicroBlaze, I believe the compiler is gcc. Depending on the version of gcc (and matching binutils), you might have the "-ffunction-sections" switch which puts each function in its own code section, and the -Wl,--gc-sections which tells the linker to drop unneeded sections. Alternatively (again, depending on the version of gcc) you might have the "--combine

-fwhole-program" switches which compiles everything at once, and treats all functions as effectively "static". Unused static functions will then be dropped. In other words, you *do* have smart linking - if the MicroBlaze gcc is a new enough version.

Well, that's cutting it a little to simple. Projects exist where not all source files are needed in every target being made.

Projects exist where it would be a complete nightmare if there were to be such a thing as "the" source directory instead of a strictly maintained tree of source directories. There's directory-based access control sometimes, or auto-generated source that has no business sitting in the same directory as the manually maintained one.

It is funny that this question turned into a rant about IDEs, Eclipse, and how difficult it is to change from one chip vendor to another.

Shameless Plug: everyone reading this thread should get a Renesas SPB:

IDEs don't need to be expensive, limited or slow. This kit shows off the Renesas HEW IDE and explains how you can do development on 8/16/32 MCUs with one IDE. It has Makefile export, project management features and integrated debugging. Plus there's DLL extensions that let you control the whole works from VB and other tools. Renesas ompilers are essentially free for

That's all true enough - and methods that suit one type of project and one type of developer might not suit everyone. Let me just say that I think the ideal situation is a one-to-one correspondence between files in your source code directory/directories and the files that are compiled and linked into the project. But if your project structure does not make this practical, you will need to do something else.

IOW; it works, unless it doesn't work. If there is to be any reuse, you're going to have files that aren't used in a particular build or version. You certainly don't want source files spread out all over the place or worse, multiple copies of the same file.