AVR Freaks

.h and .c are handled differently. -I let's you tell it the "other place" for headers but for .c if using Makefiles you might want to look at VPATH.

But most people would not use Makefiles directly (this is 2019!) but would use an IDE and they usually have mechanisms such as "Add as link" in AS7 to set up virtual paths to sources.

EDIT Google gave this which seems to cover VPATH: https://www.cmcrossroads.com/art...

I already told you the answer here is VPATH. After googling and reading about that which bit is still causing problems?

When the number of projects I had and the interconnectedness between those projects became unmanagable I was also in need of a way to re-use the same "source code library" in my projects.

After a few experiments I settled on simply using symbolic links on my linux box.

I've got just over 20 different of those libraries, which all have their own sub directory in ~/projects/avr/lib/

I have also made a makefile template from which I start new projects.

In my makefile template I have made a "link" target to make links to the libraries I want to use:

MYLIB    = /home/paul/projects/avr/lib
MKLINK    = ln -fs $(MYLIB)

link:
	$(MKLINK)/debug/debug.h
#	$(MKLINK)/keyboard/keyboard.cpp
#	$(MKLINK)/keyboard/keyboard.h
#	$(MKLINK)/lcd_hd44780/lcd_hd44780.cpp
#	$(MKLINK)/lcd_hd44780/lcd_hd44780.h
#	$(MKLINK)/lcd_pcd8544/lcd_pcd8544.cpp
#	$(MKLINK)/lcd_pcd8544/lcd_pcd8544.h
#	$(MKLINK)/lcd_pcd8544/font_5x8.cpp
#	$(MKLINK)/lcd_pcd8544/font_ubucon_11x24.cpp
	$(MKLINK)/mumarnet/mumarnet_data.cpp
	$(MKLINK)/mumarnet/mumarnet_rs485.h
#	$(MKLINK)/mumarnet/mumarnet_rf.cpp
#	$(MKLINK)/mumarnet/mumarnet_rf.h
#	$(MKLINK)/transceiver/transceiver.cpp
#	$(MKLINK)/transceiver/transceiver.h
	$(MKLINK)/timer/timer.cpp
	$(MKLINK)/timer/timer.h
####	$(MKLINK)/twi/twi.cpp
####	$(MKLINK)/twi/twi.h

The next step is to add the library files I need for that project to the list of link files:

LINKFILES = main.o
#LINKFILES += lcd_hd44780.o
#LINKFILES+= lcd_pcd8544.o
LINKFILES+= mumarnet.o
LINKFILES+= timer.o
#LINKFILES+= twi.o

After that I can use those files just as all the other files in any of my projects.

This way my libraries are compiled separately for each project, and the generated object files are also in the directory for each project.

This is a big advantage for me, because each of those library source code files has a line:

#include "main.h"

and in main.h are a bunch of #define's to adjust the behaviour of the library files.

I can reuse the HD44780 in different projects, with different pins for the LCD.

All the hardware registers get set in the object file during compile time for that specific project, which reduces code size and ram use.

Kartman said in #2 that a library is a compiled / archived file, and from the viewpoint of GCC he is right of course.

In the embedded world however it is not uncommon to call some source code files that deliver spicific functionality (such as a HD44780 driver) a library, even if they are distributed as source and compiled / linked into a project this way. It's not only "arduino" doing this.

Because of clawson I had a look into VPATH, and I glanced a bit over some pitfalls with vpath:

http://make.mad-scientist.net/papers/how-not-to-use-vpath/

but it's too much text for me to wade through. My current method seems much more straightforward and simpler.

I have no love for makfile syntax and anything to keep it simpler is a good thing in my book.

This thread touches the topic of version control; something which I find very interesting. I even have a blog where I occasionally write about this. To me version control is more than just keeping source code in SVN/Git/whatever - it involves a lot more abstract principles and methods, and applies to a lot more than just source code.

IMHO using a version control system is fundamental to almost any kind of work of any size, including private one-man projects, because:

1) it is easy to mess up and once you do that, VCS will help you go back to a previous working state

2) file history is completely automatic  ("manual file history" like writing stuff in a file header is a terrible idea IMHO)

3) libraries can be properly handled; projects (applications) can refer other projects (libraries) and even specify a unique version OR always use latest version - this allows you to develop shared libraries without inadvertently cause changes in all projects that use them

IMO a VCS also has the benefit of forcing you to always consider and think in terms of reuasbility, branching and versioning. For example, when you do use a shared project (library) you realize that the more stuff that can be put in there the better since it can be reused by other projects. That process itself highlights how different modules (.h and .c files) should be structured.

I have seen many application projects that are badly structured. They typically contain a bunch of modules with cross-dependencies all over the place - in practice no single module can be reused because it includes other modules, that also include other modules, etc. Once you want to share code, you HAVE to organize and structure your code into reusable modules.

This also forces you to think about how modules can be made reusable. One trick I use quite often is to have the module include a "myModule_config.h" file. That file is not kept in the shared project. Instead it must be defined by the application in order to define the various details of that specific implementation (I/O pins, number of "things", external functions, etc).