[Feature Request] Include File Name space change

[duaneellissd]

Our team is often integrating MULTIPLE packages and we often come across include file NAME SPACE collision problems.

For example - FreeRTOS has a "list.h" - as does a number of other packages we use. the problem is I often need to to use both.

I know what I am suggesting is an "incompatible change" - that can cause breaking for some but it is easily resolved.

Please consider creating a private include directory for all freertos header files.

This is very similar to the "X11" header files, ie: #include <x11/fonts.h>
Example: https://github.com/wxWidgets/wxWidgets/tree/master/include/wx/x11

For FreeRTOS instead of doing this:

OLD: #include "list.h"
NEW: #include "freertos/list.h"

The alternative of choosing the ORDER of "-I" paths on the command line is often not really a vialbe solution because at times you need BOTH versions of the "list.h" file

By Moving all FreeRTOS headers into an 'include/freertos' directory - this would simplify things when people use things other then freertos in a project.

[aggarg]

Thank you for your suggestion! As you mention, it is a not backward compatible change, so we will consider it in the next major release. Meanwhile, does your build system has the ability to build different source files with different include search paths (i.e. different "-I" for different source files). If yes, is it possible to include FreeRTOS-Kernel/include in your "-I" paths for FreeRTOS-Kernel sources and not for other source files? That way, your application source files would need to include FreeRTOS files like #include <FreeRTOS-Kernel/include/list.h>.

[duaneellissd]

Not practical specifying special flags on a per module or file basis is complex

our work around is this: during our ingest process we have to modify the code

just tying not to do that

[aggarg]

Not practical specifying special flags on a per module or file basis is complex

Would you please share which build system do you use?

[duaneellissd]

for our environment: we use a very bastardized version of eclipse from xilinx, another bastardized version from microsemi, a set of makefiles for a radiation hardened cortexm3,

our product source code exists across about 20 - 30 directories and 400-500 source files.

cmake does not work for these things why? cmake creates a makefile that eclipse can sort of consume. yea you can compile the code but it breaks all of the debug and index features so badly they do not work in a cmake project

what cmake cannot do is make the “right click on a variable or function goto definition” this requires the eclipse indexing to work that is only possible if you create a true cdt managed project with eclipse to set individual compile options you must right click on each file individually and set custom build rules and that is not easy to do in the tiny dialog boxes these ides have

i’ll bet most of what you deal with is 20-30 total files in 1 or two directories, doing what i describe is easy at that scale. when you have 10x that it is more complicated. the scale is very important.

as for IDEs.. for some cortex things we use Kiel, some use the bastardized vendor eclipse, i mostly use emacs, others use vscode [but that does not work for riscv] others use various vendor supplied eclipse tools, other use makefiles + vim

for cpus we use riscv softcores in a few fpgas, we use microblaze and various cortex m0 and m3 plus arm 64bit

we build on linux, and windows hosts

[cookpate]

I have a couple of ideas that might be worth trying.

Specifying the generator for CMake:

cmake -G <Generator Name>
Generators
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
* Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - Ninja           = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files
                                 (deprecated).
  CodeLite - Ninja             = Generates CodeLite project files
                                 (deprecated).
  CodeLite - Unix Makefiles    = Generates CodeLite project files
                                 (deprecated).
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Kate - Ninja                 = Generates Kate project files (deprecated).
  Kate - Ninja Multi-Config    = Generates Kate project files (deprecated).
  Kate - Unix Makefiles        = Generates Kate project files (deprecated).
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files
                                 (deprecated).
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files
                                 (deprecated).

I have not used CMake for generating Eclipse projects, and I am not sure if the version of Eclipse this creates projects for is suitable.

There is also the CMAKE_EXPORT_COMPILE_COMMANDS variable (e.g. CMake -DCMAKE_EXPORT_COMPILE_COMMANDS=1).
This produces a compile_commands.json in the build directory. This is often used by language servers such as clangd to get source information.
I am not sure how difficult it would be to use this file to generate Eclipse's missing source information.