[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.

[duaneellissd]

You suggestion is a bit off topic for FreeRTOS - but I'll answer it because it provides color to the problem at hand.

YES we use the "Eclipse CDT4 - Unix Makefiles" now. YES - Cmake can customize the compile steps for each C file but CMAKE is not a good overall solution for us for many other reasons.

The primary reason CMAKE is not a good solution is the ECLIPSE INDEX ability does not work with CMAKE.

Stated differently: CMAKE DOESNOT* generate a First Class Eclipse Project - it creates a MAKEFILE that Eclipse can use. that is where CMAKE stops. Makefile builds do not support C language indexing.

INDEXING DEFINED: - In Most IDEs - you can CLICK on a function or variable and "goto definition" - this does not work with a CMAKE created project.

part 2 - is XILINX provides the Eclipse solution for XILINX Chips [and it is very customized for XIlinx things] - getting them to change will not happen. Same problem with MicroSemi (now Microchip) - they will not change their Eclipse solution either - they have no interest in helping with that.

Other vendor versions of Eclipse we use are from STM (CubeSuite) and a stock "Eclipse" one from a small specialty vendor that has a very unique chip we use, but we also use KEIL - and that is not supported by CMAKE

Some of my team can manage Emacs or VI and a Makefile - some - whimper and shed tears at the though of not having an IDE and cling to it for dear life.

BUT NONE of that solves the problem when two packages have their own "list.h" file... and two packages want you to have different include path orders to solve a problem that would have been solved if they just put their files in a "name-spaced" directory, ie: do not include "list.h" - instead include "freertos/list.h" - would solve many things.

We resort to doing exactly that on some projects.

My request {although breakings} is to ask that FreeRTOS going forward switch to this style. As for breaking, the customer a simple solution: Step 1 - point the compiler at TWO directories, First the top level ${ROOT}/include directory and Second the ${ROOT}/include/freertos directory.

[cobusve]

This is awesome information, thank you so much for taking the time to get into the details of this. As we are working on Safety Certification we will have to move some things around and this is probably the best time to accommodate a change like this.

[archigup]

Hey, we agree that this would be a welcome change, though will have to wait until the next major version.