2009-03-16 6 views
1

Ich baue für mehr als zwei Dutzend Ziele aus einem Quellbaum mit normalerweise drei aktiven Zweigen mit sowohl Produktions- als auch Debug-Builds. Bis heute habe ich ein persönliches Makefile verwendet, das das Ziel definiert, das ein gemeinsames Makefile enthält, das die Kompilierflags definiert, die dann das Makefile aus einem bestimmten Quellbaum enthält. Das funktioniert, aber ich kann nicht anders, als zu denken, dass es einen besseren Weg gibt.Verwenden Sie sqlite zum Verwalten von Makefile-Build-Flags

Ich möchte eine SQLite3-Datenbank verwenden, um eine vollständige Liste der Build-Flags zu speichern und zu organisieren. Zur Kompilierzeit würde die Datenbank abgefragt werden, um Flags basierend auf Projektversion, Plattform und Entwickler/Produktion zu generieren und den Build zu starten.

Diese Datenbank wäre ein einzelner Ort, an dem ich meine aktuellen Einstellungen für alle meine Entwicklungsversionen dokumentieren und verfolgen kann. Ein Basissatz von gespeicherten Flags würde durch granularere Flags bei Version, Zielplattform überschrieben werden und dann Qualitätsstufen aufbauen.

Als Teil der Implementierung von so etwas würde ich auch eine Handvoll Shellskripte erstellen, um die Datenbank zu manipulieren und Flags zu setzen und anderen Entwicklern in meinem Labor dies leichter zu erlauben.

Wurde das schon gemacht? Gibt es Beispiele für so etwas?

Gibt es einen anderen/besseren Weg, damit umzugehen?

Zwei Dinge: * Ich kann die Makefiles des ursprünglichen Projekts nicht ändern. * Der Versuch, etwas wie Automake zu verwenden, wäre umständlich, da die erforderliche Anzahl von Flags konfigurieren würde, um eine Debugging-Ebene in einem vorhandenen Modul der Codebasis zu aktivieren.

Antwort

0

IMHO, mit einer Datenbank dafür ist Overkill. Die Verwendung von Makefile-Includes ist eine saubere und einfache Möglichkeit, dies zu umgehen. Was sind Ihre Sorgen/Probleme/Probleme in Bezug auf diesen Ansatz? Vielleicht gibt es eine Möglichkeit, Ihre Makefiles neu zu strukturieren, um Ihre Ziele zu erreichen, ohne eine Datenbank hinzuzufügen und ohne auf ein komplett anderes Buildsystem umzusteigen.

1

Ich vermute, dass Sie vielleicht einen Blick auf ein anspruchsvolleres Build-System werfen möchten. Werfen Sie einen Blick auf ant, jam und andere Build-System-Tools. Ich denke, dass die übliche GNU-Art zu tun, was Sie beschreiben, durch ./configure (autoconf) Skripte ist, obwohl ich sehen kann, dass die Verwaltung der verschiedenen Konfigurationen schwierig wäre.

Obwohl das Erstellen eines eigenen Makefile-Konfigurationssystems möglich ist, würde ich vermuten, dass die Verwendung eines Standard-Build-Systems die richtige Antwort ist, wenn Sie möchten, dass Ihr Code breiter eingesetzt wird.

+0

Dies muss abgesehen von den ursprünglichen Makefile-Quellen getan werden, da das Projekt Hunderttausende von Codezeilen enthält und die Makefiles 13 Jahre Tweaks haben, die eine Konvertierung in so etwas wie autoconf niemals überleben würden. –

+0

Whoa ... seine Slace! – dicroce

+0

Ich kann die originalen Makefiles nicht so schreiben, stau und autoconf wird in diesem Fall nicht funktionieren –

Verwandte Themen