4

I have started to develop the C language software in the Xilinx Vitis IDE which Eclipse based. Organization of my project is following:

-Application
-Drivers
 -drivers
  -Adc
  -Pwm
   -Pwm.c
   -Pwm.h
-Utils
 -Bits.h
 -Maths.h

All the directories i.e. Application, Drivers and Utils are linked into the workspace via "Link folder" option. The only one way how I was able to include the Bits.h into the Pwm.c was to specify the whole path to the Bits.h on my disk. Otherwise the compiler reports fatal error: Bits.h: No such file or directory. The compilation process is managed by the automatically generated makefile with this content:

# Makefile generated by Xilinx.

PROCESSOR = ps7_cortexa9_0
LIBRARIES = ${PROCESSOR}/lib/libxil.a
BSP_MAKEFILES := $(wildcard $(PROCESSOR)/libsrc/*/src/Makefile)
SUBDIRS := $(patsubst %/Makefile, %, $(BSP_MAKEFILES))


ifneq (,$(findstring win,$(RDI_PLATFORM)))
 SHELL = CMD
endif

all: libs
    @echo 'Finished building libraries'

include: $(addsuffix /make.include,$(SUBDIRS))

libs: $(addsuffix /make.libs,$(SUBDIRS))

clean: $(addsuffix /make.clean,$(SUBDIRS))

$(PROCESSOR)/lib/libxil.a: $(PROCESSOR)/lib/libxil_init.a
    cp -f $< $@

%/make.include: $(if $(wildcard $(PROCESSOR)/lib/libxil_init.a),$(PROCESSOR)/lib/libxil.a,)
    @echo "Running Make include in $(subst /make.include,,$@)"
    $(MAKE) -C $(subst /make.include,,$@) -s include  "SHELL=$(SHELL)" "COMPILER=arm-none-eabi-gcc" "ASSEMBLER=arm-none-eabi-as" "ARCHIVER=arm-none-eabi-ar" "COMPILER_FLAGS=  -O2 -c" "EXTRA_COMPILER_FLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -g -Wall -Wextra -g3 -O0"

%/make.libs: include
    @echo "Running Make libs in $(subst /make.libs,,$@)"
    $(MAKE) -C $(subst /make.libs,,$@) -s libs  "SHELL=$(SHELL)" "COMPILER=arm-none-eabi-gcc" "ASSEMBLER=arm-none-eabi-as" "ARCHIVER=arm-none-eabi-ar" "COMPILER_FLAGS=  -O2 -c" "EXTRA_COMPILER_FLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -g -Wall -Wextra -g3 -O0"

%/make.clean: 
    $(MAKE) -C $(subst /make.clean,,$@) -s clean 
clean:
    rm -f ${PROCESSOR}/lib/libxil.a

It is obvious that my "solution" is unacceptable. So I would like to ask you for an advice how to resolve this issue correctly. Thanks in advance for any suggestions.

Steve
  • 805
  • 7
  • 27
  • Probably you have a setting somewhere in your IDE to list the include directories which will then be added to makefile automatically. – Eugene Sh. Jun 11 '20 at 15:04
  • @EugeneSh.thank you for your reaction. Do you think that the problem is due to the Utils directory is missing in that list? – Steve Jun 11 '20 at 15:09
  • Most likely. Not familiar with this IDE, but any sane one would provide such a setting. Is it Eclipse-based by a chance? – Eugene Sh. Jun 11 '20 at 15:11
  • If it is and the project is CDT-managed, then got to project properties->C/C++ General->Paths and Symbols and add your paths on the "Includes" tab – Eugene Sh. Jun 11 '20 at 15:13
  • As far as I understand correctly your idea you suggest to move the whole path from the Pwm.c module into the "project properties". If so do you think that it is not a problem in case I would in future cooperate with another guy on this software? – Steve Jun 11 '20 at 15:20
  • You don't change anything in the code, you only point the IDE where your include files are stored. And then the IDE will modify the makefile in such a way that these paths are passed to the compiler. – Eugene Sh. Jun 11 '20 at 15:22
  • I see that I will not modify the code. My uncertainty comes from the fact the other person could have different organization on its hard drive. So this seems me little bit fragile solution. I would say that more robust would be to have the Bits.h location relative as far as the workspace. – Steve Jun 11 '20 at 15:31
  • 1
    The paths can be relative to the project. If the "other person" project structure is different - then you have a problem on a different level. – Eugene Sh. Jun 11 '20 at 15:33
  • By the term different organization I meant that the project could be located somewhere else but its structure has to the same. – Steve Jun 11 '20 at 15:36
  • Then it should not be a problem at all. And it also depends what exactly you are sharing. Are you sharing the project setting or only the sources? – Eugene Sh. Jun 11 '20 at 15:38
  • My first idea was to share only the sources. – Steve Jun 11 '20 at 15:39
  • Then let every team member to configure their workspace and that's it. If you want to share all-inclusive solution, then you might want to switch to "Makefile" project and step away from automatically managed one. – Eugene Sh. Jun 11 '20 at 15:40
  • I have to say that I am not familiar with the Eclipse IDE. Do you know how to achieve relative path setting in respect to the project location? Is it possible to do that in the Properties->C/C++ General->Paths and Symbols and in the Includes tab use some variable specifying the workspace location? – Steve Jun 11 '20 at 15:46
  • I have attempted to find solution and I have found [this](https://stackoverflow.com/questions/3997152/getting-eclipse-cdt-to-use-relative-include-paths-in-generated-makefiles). Do you think the second answer is usable? – Steve Jun 11 '20 at 15:53
  • The accepted answer is stating that the include paths added there are relative anyway. You can probably check the generate makefile to make sure it is true. – Eugene Sh. Jun 11 '20 at 16:00
  • @EugeneSh. Thank you very much for your help. I have just set the paths in Properties->C/C++ General->Paths and Symbols->Includes tab and it works. One question popped up in my head in relation with paths settings. Do you think that it is better to have the include directives in form #include "Bits.h" or in form #include "Utils/Bits.h"? – Steve Jun 12 '20 at 06:59

1 Answers1

2

You can add include paths to the project. These are paths where the compiler will search for include files. Any include file located in one of the directories in the include paths list should be found; you do not need to specify its path when including the file.

How you do this in the Xilinx environment appears to depend on how your project is set up.

If it is a managed make project:

Properties -> C/C++ Build In "Tools Settings" tab select the "Include Paths"

If it is a standard make project:

Properties->C/C++ Include Paths and Symbols>

Then "Add External Include Path"

If it gives you the option to add the path as absolute or relative path, choose relative path; this allows another user to put the project, with the same internal directory structure, in a different place on the hard drive, which is what you want. In the screenshots in the documentation I referenced, the paths appear relative.

See this documentation for more details, screenshots, etc.

Note: I am answering based on the documentation; I have not worked with this IDE myself.

Note also that you can use relative paths in an #include directive, but they are not necessarily relative to the location of the file that includes them. They are more likely to be relevant to the root of the project (basically, wherever 'make' will be effectively run).

Basya
  • 1,477
  • 1
  • 12
  • 22