[GCC] how deep is too deep

[andersm]

Do you understand how the GNU C preprocessor works, and how it searches for files? If not, I suggest reading especially sections 2.1 and 2.3 of the documentation.

[Simon]

Are *all* the files that include "project_variables.h" in the same folder as itself
 and "main.c"?

No,

so how do I write so called portable code to be used on multiple projects if I can't call one project specific file that is in the main folder of the program. So project specific files have to go into my general libraries folder or I'll have to create yet another global folder to put all project specific stuff in...... So much for an IDE!

[Ian.M]

You can add the project folder to the GCC include search path using the GCC -Idirectory command line option.   Use the Atmel Studio macro for the fully qualified project folder name and it will remain correct if you copy/move the project

[Simon]

OK that makes sense. So what do I call the current project folder so that it remains portable ?

[Ian.M]

You'll have to figure that out for yourself as I don't use Atmel Studio.

[Mechatrommer]

Right, next problem:
#include "project_variables.h"
No such file or directory. This is included in several files but I only get one instance of the error. Um it is either there or not! what is the compiler playing at. I have the file in the same folder as the main.c file.

i tried to emulate your problem here... i have 2 c files main.c located in project folder, and another xxx.c located in "project folder\xxx".. and a project_variables.h located in project folder. both c have #include "project_variables.h". main.c doesnt report error, xxx.c does.

simple solution if you dont want to setup project configuration (include directories) is, retype in xxx.c as #include "..\project_variables.h" you use "..\" to ask compiler to use (search) relative path up one step from "project folder\xxx" where xxx.c is located which is "project folder".

two steps up you use "..\..\" and so on. one step down, say if you have yyy.h in "project folder\xxx" and you want to include it in main.c, you use #include "xxx\yyy.h" fwiw..

[Simon]

No the problem is that the project folder is not part of the search paths, how do I get Atmel Studio to use the current folder? The idea is that my standard header files will stay in one location while copies of the project files are made and in a different location. So I am writing a set of templates that will include some project specific files. When I make a copy of my template code the new copy will have a local project variables header that the standard files need to look at now instead.

[Simon]

I give up, I will do it the horrendously dumb way and put everything in one folder and copy it over and over. I searched and found no roference on how to do something so basic as make the current codes folder a default location 

[Mechatrommer]

Menu -> Project -> Configuration Options -> Include Directories ...
other than that, your project is really special...

[newbrain]

how do I get Atmel Studio to use the current folder?

See the attached picture.
You can add include paths by right-clicking on the project (iMAC) and selecting "Properties".
In the newly opened tab, click on toolchain then "directories".
By clicking on the green "+" icon, you can add any directory.
The path can be relative (see below!), absolute or use any of the internal AS variables.
The available variables are described here

"..\project_variables.h" "..\" "project folder\xxx"  "..\..\" "project folder\xxx" "xxx\yyy.h"

The use of a backslash in the q-char-sequence (that is: "the stuff between quotes in an #include directive") is undefined behaviour in most C and C++ standards.
It might work today, but there's no guarantee it will continue to do so.
Please refrain from using it, as it is not needed: any self respecting modern compiler, and GCC is one, will allow using '/'.

[Simon]

Ah of course relative path will mean itself

[Simon]

the result is ".."

[ajb]

so how do I write so called portable code to be used on multiple projects if I can't call one project specific file that is in the main folder of the program. So project specific files have to go into my general libraries folder or I'll have to create yet another global folder to put all project specific stuff in...... So much for an IDE!

There are a couple of ways of connecting portable library-type code to project-specific code.  Which works best depends on the nature of the project and the library.

1. Your library has no dependencies on project-specific code or data: In this case your library declares its public functions (and if necessary, variables) to the project code via a header file that the project #includes.  This is the simplest case.

2. Your library depends on a set of project-specific functions that will not change as the application runs: In this case your library can declare (but not define!) a set of functions that are defined within the project. Your library will know that those functions exist because it declared them, and as long as the linker can find their definitions (which your IDE should take care of) everything will come together properly.  Your library could optionally provide weak definitions (__attribute__((" weak")) in GCC), which allows the library to provide default functions that your project may or may not override.

3. Your library depends on a set of project-specific functions that may change depending on the application state:  In this case your library might declare a set of function pointers to which your project will assign the addresses of functions that provide the project-specific code.  This is common if the library will need to access different physical interfaces within the application, IE, fatfs, which might target both on-board flash and an SD card.  Often the function pointers are gathered in a struct type provided by the library. 

As a general rule, your application should reach into the library and not the other way around.  If the library needs to act on data 'owned' by the application, then it's often preferable for the application to pass a reference to that data into the library.  If the library and the application really need to have direct access to a shared variable, then you can define that variable in the library and expose it to the application via the library's header file.  The extern keyword is helpful here, as it allows you to declare a variable without redefining it. 

You might have a situation where you want to configure a library for your application via the preprocessor--in other words, you want to be able to #define a bunch of things in your project that influence the behavior of the library.  In this case, your library can do something like #include "lib_conf.h", where lib_conf.h is stored in one of your compiler's search paths.

It's really crucial to understand the difference between a definition and a declaration, so if that's not yet clear to you, definitely read up on the subject as it's crucial to understanding how a pile of C comes together into a working program.

[westfw]

how do I get Atmel Studio to use the current folder?

The problem is probably that AS does the actual builds down in some "build" directory, so the "current directory" is not what you expect, and #include paths can get screwed up.
It looks like all of the default paths added to the compile use "..", and already include "../src" - exactly where do you have your "project_variables.h" file, anyway?  It probably should be in "projectdir/src", rather than "projectdir"(This is all in the ProjectProperties/..C Compiler/Directories panel, and you can add additional include directories.)

Studio also has some macros or environment variables that you could use in these paths:
https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-D42F376A-5538-4C9A-A8A3-606B3573D8C8