Die Config.in.generated wird aus allen Unterverzeichnissen in "make" generiert.
Um da ein eigenes Projekt/Programm einzufügen, brauchst Du also nur das passende Verzeichnis anlegen.
Darin muß dann wiederum eine Datei "<package>.mk" liegen, die auf verschiedene "make"-Makros zugreifen kann und eines davon wäre dann "$(PKG_LOCALSOURCE_PACKAGE)", mit dem man "ansagen" kann, daß die Quellen für das Paket nicht aus dem Internet kommen sollen, sondern aus dem lokalen Unterverzeichnis "src".
Wie das ansonsten geht und was da in einem "mk"-File als Beispiel definiert sein kann, kannst Du Dir in meinem "decoder"-Projekt ansehen:
https://github.com/PeterPawn/decoder
Das Projekt ist in dieser Form dafür gedacht, um einfach in ein Unterverzeichnis im "make"-Zweig einer Freetz-Installation eingebunden zu werden (das muß dann allerdings auch "decoder" heißen, weil das "mk"-File diesen Namen trägt) und mit den beiden Dateien "Config.in" und "decoder.mk" hast Du zumindest mal zwei "Vorlagen", wie das aussehen könnte. Die Make-Makros sind irgendwo (in Ansätzen zumindest) dokumentiert und man kann einige davon durchaus sinnvoll nutzen, wenn man das eigene Projekt in den Build-Prozess bei Freetz einbetten will.
Unterhalb von "source" brauchst/solltest Du nichts ablegen ... da landen die entpackten und gepatchten Quellen der Pakete und dort vorgenommene Änderungen sind schneller wieder weg, als man gucken kann, wenn nach einer Änderung im "make/<package>"-Verzeichnis die Quellen dann neu "entpackt" (bzw. bei einem lokalen Paket dann halt nur aus "src" kopiert) werden.
Abgesehen davon solltest Du noch mal Ordnung in die Zahlen (und vielleicht auch in die Gedanken) bringen ... mal ist von "freetz-1.1.4" die Rede, mal von "freetz-1.4.1" (und mit der letzteren Nummer gibt es durchaus auch noch ein "freetz-linux"-Image:
https://sourceforge.net/projects/freetz-linux/) und eigentlich könnte man ja auch gleich das neue 1.5.1-Image nehmen, wenn das irgendetwas mit der Version des Linux-Images zu tun haben soll. Wobei man ein Image mit der Nummer 1.4.1 irgendwie auch nicht "schon vor ein paar Jahren" benutzt haben kann, denn die 1.4.1 gibt es ja auch erst seit 2 1/2 Jahren. Ich hoffe, Du verstehst, warum die Zahlen "etwas wirr" erscheinen und der Text rundherum keinen richtigen "Kontext" bildet.
Aber vollkommen egal, welches Image man nun mit welchem VM-Host (oder auch "native") benutzt ... nach einem "git clone ..." ohne Angabe eines Zielverzeichnisses, entsteht ein Verzeichnis "freetz" mit dem Klon und warum sollte man dieses Verzeichnis jetzt "freetz-1.4.1" (oder auch "freetz-1.1.4") nennen? Welchen Bezug hätte diese "Nummer", wenn man das oben erwähnte "git clone" verwendet hat? Wieso könntest Du dann:
Bevor ich jetzt unter freetz-1.4.1 etwas versemmele will ich noch mal nachfragen:
unter freetz-1.4.1 irgendetwas "versemmeln"?
Vor allem kann man eigentlich nur wenig falsch machen ... funktioniert die eigene Kopie des Freetz-Master-Repos nicht mehr, weil man darin Unsinn verzapft hat, klont man das einfach in ein anderes Verzeichnis (nach der URL
darf ja auch noch ein lokaler Verzeichnisname stehe, unter dem das gespeichert werden soll) erneut und kann dann wieder "von vorne" beginnen und den eigenen Fehler beim zweiten Anlauf einfach weglassen.