2010-12-29 4 views
0

Ich habe ein großes Projekt, das ziemlich heterogen ist - verschiedene Sprachen und Compiler sind involviert, die insgesamt einen Build mit Hilfe von GNU make erzeugen.Projekt Ordnerstruktur: sind auch Makefiles Quellcode?

Das Projekt Ordnerstruktur umfasst:

project 
    src 
     haxe   --Haxe source code 
     graphics  --Embeddable graphic resources 
     locale  --Locale-specific resources 
     chinese --Chinese language resources 
     english --Generic English resources 
    build 
     china   --Chinese market 
     debug  --Debugging/Testing for developer(s) 
     release --Release 
     europe  --European market 
     debug  -- ... 
     release -- ... 

Alle durch Aufbau und Betrieb produziert baut ‚machen‘. Was ich nicht entscheiden kann ist, ob diese Makefiles auch in das Verzeichnis 'src' geschrieben werden sollten? Ich betrachte das Originalmaterial, das ich manuell schreibe, als Quellcode (da es von mir stammt und nicht von irgendeinem anderen Programm stammt) und ich schreibe meine Makefiles per Hand. Ein weiterer Grund dafür ist, dass NUR das 'src'-Verzeichnis ein Git-Repository ist - ich brauche nicht wirklich etwas anderes zu tracken. Lege ich alle Makefiles in 'src'?

Antwort

2

Was befindet sich derzeit in Ihrer build Verzeichnisstruktur? Ist das die kompilierte Ausgabe?

Intuitiv, als ich ein build Ordner einen src Ordner angrenzenden sehen (und ich kann aus einer ganz anderen Entwicklung Welt als du, so „intuitiv“ ist ein relativer Begriff kommen werden), erwarte ich den Quellcode des Programms in der sein Letzteres und die Skripte/Tools/etc. benötigt, um es in der ehemaligen zu bauen. Die Skripte (makefiles in diesem Fall, obwohl möglicherweise auch andere Dinge enthalten) sind selbst Quellcode, wie Sie sagen, aber sind nicht die Quelle des Programms. Der Unterschied ist, dass man "was gebaut wird" und der andere "wie man es baut" ist.

Wenn ich Sie richtig verstehe, ist src, was an Ihre Versionskontrolle gebunden ist und build nicht ist? Unter diesen Umständen würde ich wahrscheinlich ein build (oder builder oder building oder etwas dieser Art) unter src schaffen, um die Skripte aufzunehmen. Es mag etwas unintuitiv sein, dass es einen anderen Ordner hochklettern muss, bevor es seine Ausgabe produziert, aber es sollte gut neben den Ressourcenordnern sitzen, die Sie dort bereits haben.

+0

Das Verzeichnis 'build' enthält maschinell erzeugten Inhalt, der aus Quellcode generiert wird - dies sind Binärdateien, Bibliotheken, Laufzeit-Assets - alles, was beim Kunden ankommt. Tatsächlich enthält das 'src' den Quellcode des Programms, und' build' enthält auch Makefiles, die 'make' verwenden, um den Inhalt dieses Verzeichnisses zu erzeugen. 'src' ist an das Versionskontrollsystem (git) gebunden, nichts anderes ist es. Allerdings habe ich mich gefragt, ob Makefiles auch Quellcode sind, da viele meiner Makefiles von Hand geschrieben wurden und viele Informationen enthalten, die für einen erfolgreichen Build wichtig sind. – amn

+0

@amn: also sind Ihre Makefiles derzeit nicht unter Quellcodeverwaltung? –

+0

@Tom nein sind sie nicht. Aus diesem Grund denke ich darüber nach, sie zu bewegen. Ich denke nicht, dass irgendetwas anderes als Quellcode Versionskontrolle benötigt. Und meine Makefiles werden mit wachsendem Projekt immer komplexer und enthalten wertvolle Informationen. Zum Beispiel baue ich eine Adobe Flash SWF-Datei aus einem ganzen Verzeichnis von Quellcode. Die SWF-Dimensionen (Breite, Höhe, Framerate) werden jedoch als Befehlszeilenoptionen für den Compiler angegeben und sind daher nicht Teil des Quellcodes, obwohl sie auch das Projekt ausmachen, nicht wahr? – amn

1

Üblicherweise erstellen Sie ein Makefile außerhalb Ihres src/-Verzeichnisses, das Ihr Projekt erstellt, und innerhalb dieses src/-Verzeichnisses erstellt ein anderes Makefile einzelne Module. Das heißt, ich denke in Ihrem Fall ist es ausreichend, Ihr Makefile nur in src zu behalten. Ich bin mir nicht sicher, ob das zutrifft, aber vielleicht möchten Sie sich das GNU autoconf-Paket anschauen, das genau für diese Art von Dingen verwendet wird.