Build-Systeme Teil 3: SCons

Mr. N

Ich möchte nur mal die Idylle zerstören:

SCons hat ein paar Probleme, gerade was Konfiguration von externen Komponenten angeht. Es ist recht schwierig, mit SCons ein modulares Projekt aufzusetzen. Außerdem wird es sehr schnell sehr langsam (IIRC ~10-20 Sekunden Startzeit für ein mittelgroßes Projekt, 40 KLOC).

Ich kenne zwei Projekte, die SCons erwägt, aber dann doch irgendwann verworfen haben:

KDE 4
GOTT (:D)

Andererseits ist SCons natürlich viel angenehmer als zum Beispiel Makefiles oder auch autotools.

__HIRSCH_H__

Mr. N schrieb:

Ich möchte nur mal die Idylle zerstören:

SCons hat ein paar Probleme, gerade was Konfiguration von externen Komponenten angeht. Es ist recht schwierig, mit SCons ein modulares Projekt aufzusetzen. Außerdem wird es sehr schnell sehr langsam (IIRC ~10-20 Sekunden Startzeit für ein mittelgroßes Projekt, 40 KLOC).

Kann ich so nicht bestätigen, ich hab hier ein Projekt mit 41kloc uns das sind die Timings für einen Rebuild ohne Änderung:

Total build time: 3.545805 seconds
Total SConscript file execution time: 1.095926 seconds
Total SCons execution time: 2.449879 seconds
Total command execution time: 0.000000 seconds

Es stimmt das Scons bei grossen Projekten langsam wird und nicht so gut skaliert, aber das beginnt erst bei einer anderen Dimension.

Das mit dem Problem bei modularen Projekten kann ich so auch nicht bestätigen sondern eher umkehren, wir haben hier ein Projekt aus 20 einzelnen Plugin-Bibliotheken die teilweise voneinander abhängen, da ist es sehr konfortabel dass SCons sich die Checksummen der Bibs merkt und bei Ändering die abhängigen Bibs neu baut.
In Zukünfigen Versionen soll sogar nur neu gebaut werden wenn die Binärkompatibilität nicht mehr gewährleistet ist (also sich Funktionssignaturen geändert haben). Das kann meines wissens kein anderes build-tool.

HIRSCH_H schrieb:

Mr. N schrieb:

Ich möchte nur mal die Idylle zerstören:

SCons hat ein paar Probleme, gerade was Konfiguration von externen Komponenten angeht. Es ist recht schwierig, mit SCons ein modulares Projekt aufzusetzen. Außerdem wird es sehr schnell sehr langsam (IIRC ~10-20 Sekunden Startzeit für ein mittelgroßes Projekt, 40 KLOC).

Kann ich so nicht bestätigen, ich hab hier ein Projekt mit 41kloc uns das sind die Timings für einen Rebuild ohne Änderung:
Total build time: 3.545805 seconds
Total SConscript file execution time: 1.095926 seconds
Total SCons execution time: 2.449879 seconds
Total command execution time: 0.000000 seconds

Entweder stimmt da meine Erinnerung nicht, oder die Projekte sind etwas unterschiedlich strukturiert.

HIRSCH_H schrieb:

Es stimmt das Scons bei grossen Projekten langsam wird und nicht so gut skaliert, aber das beginnt erst bei einer anderen Dimension.

Das mit dem Problem bei modularen Projekten kann ich so auch nicht bestätigen sondern eher umkehren, wir haben hier ein Projekt aus 20 einzelnen Plugin-Bibliotheken die teilweise voneinander abhängen, da ist es sehr konfortabel dass SCons sich die Checksummen der Bibs merkt und bei Ändering die abhängigen Bibs neu baut.

Das war ja auch nicht das Problem. Das Problem war das Konfigurieren der Libs. Man muss sich ja quasi für jedes Modul ein eigenes Environment basteln und 20-mal pkg-config aufrufen find ich nicht so geil.

(Unser Workaround war dann, mittels -Wl,--as-needed nur die Bibliotheken zu linken, von denen mindestens eine Funktion verwendet wurde. Ist allerdings sehr... Non-GNU binutils oder vielleicht auch nur solche für Nicht-ELF-Plattformen würde ich dafür nicht unbedingt verwenden wollen. Es gab natürlich immer noch drei unterschiedliche Environments...)

HIRSCH_H schrieb:

In Zukünfigen Versionen soll sogar nur neu gebaut werden wenn die Binärkompatibilität nicht mehr gewährleistet ist (also sich Funktionssignaturen geändert haben). Das kann meines wissens kein anderes build-tool.

Wie, wird SCons jetzt wieder weiterentwickelt?

__HIRSCH_H__

Wie, wird SCons jetzt wieder weiterentwickelt?

Das wurde eigentlich nie eingestellt, die letzte Version iss vom 12.04.2007. Man sollte auch die "latest" version nehmen, nicht die "stable" weil die hat schon n paar Jahre aufm Buckel. Das iss vll. auch der Grund für die unterschiedlichen Eindrücke im Bezug auf die Geschwindigkeit.

HIRSCH_H schrieb:

Wie, wird SCons jetzt wieder weiterentwickelt?

Das wurde eigentlich nie eingestellt, die letzte Version iss vom 12.04.2007. Man sollte auch die "latest" version nehmen, nicht die "stable" weil die hat schon n paar Jahre aufm Buckel. Das iss vll. auch der Grund für die unterschiedlichen Eindrücke im Bezug auf die Geschwindigkeit.

Nee das war die "latest" von vor einem halben Jahr. Ich erinnere mich, dass die "latest" LoadableModule hatte und die "stable" nicht.

joomoo

Ich hab gerade noch eine Frage die ich nicht mit google oder in der Doku finden konnte:

Wenn ich früher mit g++ `pkg-config gtkmm --cflags --libs` kompiliert habe, wie sieht das in der SConstruct dann aus?
Also, dass SCons fürs Kompilieren ein `pkg-config gtkmm --cflags` mit dranhängt und beim Linken ein `pkg-config gtkmm --libs`?

GPC

env = Environment(CCFLAGS = '-O2')

def CheckPKGConfig(context, version):
     context.Message( 'Checking for pkg-config... ' )
     ret = context.TryAction('pkg-config --atleast-pkgconfig-version=%s' % version)[0]
     context.Result( ret )
     return ret

def CheckPKG(context, name):
     context.Message( 'Checking for %s... ' % name )
     ret = context.TryAction('pkg-config --exists \'%s\'' % name)[0]
     context.Result( ret )
     return ret

# Den check auf pkg-config und gtkmm hab ich auskommentiert
# Configuration:
#conf = Configure(env, custom_tests = { 'CheckPKGConfig' : CheckPKGConfig,
#                                       'CheckPKG' : CheckPKG })
#if not conf.CheckPKGConfig('0.15.0'):
#     print 'pkg-config >= 0.15.0 not found.'
#     Exit(1)
#if not conf.CheckPKG('gtkmm-2.4 >= 2.6.2'):
#     print 'gtkmm-2.4 >= 2.6.2 not found.'
#     Exit(1)
#
# Your extra checks here
#env = conf.Finish()

# Now build:

#Vermutlich kommen hier noch weiter Dateien rein :-D
sourcelist = Split("""
                        src/main.cpp
                   """)

env.ParseConfig('pkg-config --cflags --libs gtkmm-2.4')
env.Program('main', sourcelist)

joomoo

Danke, klappt!
Kann man auch noch einstellen, dass --cflags beim build und --libs nur beim linken genommen wird?

GPC

Bin ich im Moment überfragt, sorry.

joomoo

Ich hab's hingekriegt:

env.Append(CCFLAGS = '`pkg-config glib-2.0 --cflags`', LINKFLAGS = '`pkg-config glib-2.0 --libs`')

Funktioniert wunderbar, das gute ist, dass man jetzt auch nicht mehr so lange Compilier-Zeilen hat.

mfg.

GPC

cool, danke

joomoo

Noch eine kleine Korrektur:

env.Append(CCFLAGS = '`pkg-config glib-2.0 --cflags`', _LIBFLAGS = ' `pkg-config glib-2.0 --libs`')

Damit funktioniert's auch mit statischen Libraries. Das einzige was mich noch stört ist das Leerzeichen was man an den Anfang von _LIBFLAGS setzen muss.

weiß jemand wie ich scons wieder löschen kann??
bei removescons bekomme ich nur eine Fehlermeldung das das programm zurzeit läuft.

GPC

Welches OS verwendest du denn?

ich verwende WinXP.

ich hab glaube totalen mist gebaut bei der installation.

zuerst hab ich es in eine Python installation(2.2) die es schon auf dem system gab installiert. nur da passierte nichts wenn ich scons in der shell eingegeben habe.

dachte es liegt an Python habe python 2.5 installiert und scons auchnochmal.
wieder konnte ich scons nicht starten.
dann habe ich den pfad von python2.5 zum systempfad hinzugefügt.
dann kannte er den befehl scons, nur leider will er bei mir nun das scons öffnen das ich bei python 2.2 installiert hatte...leck.

jetzt möchte ich gerne wissen wie ich das scons schön wieder vom rechner entfernen kann.

joomoo

nash35 schrieb:

ich verwende WinXP.

ich hab glaube totalen mist gebaut bei der installation.

zuerst hab ich es in eine Python installation(2.2) die es schon auf dem system gab installiert. nur da passierte nichts wenn ich scons in der shell eingegeben habe.

dachte es liegt an Python habe python 2.5 installiert und scons auchnochmal.
wieder konnte ich scons nicht starten.
dann habe ich den pfad von python2.5 zum systempfad hinzugefügt.
dann kannte er den befehl scons, nur leider will er bei mir nun das scons öffnen das ich bei python 2.2 installiert hatte...leck.

jetzt möchte ich gerne wissen wie ich das scons schön wieder vom rechner entfernen kann.

Wie hast du scons installiert?

einfach den aktuellen Win32 installer benutzt

joomoo

nash35 schrieb:

einfach den aktuellen Win32 installer benutzt

Dann deinstallierst du in dem du in den Systemsteurungen auf Software gehst und dann SCons rauspickst.

damn jetzt taucht es doch in der Systemsteurungen auf.

Frage, muss man bei SCons noch irgendwas angeben einen Pfad zum compiler(habe VC 2005) oder so?
so richtig hab ich das mit der idee von scons nämlich noch nicht geblick..

GPC

nash35 schrieb:

Frage, muss man bei SCons noch irgendwas angeben einen Pfad zum compiler(habe VC 2005) oder so?
so richtig hab ich das mit der idee von scons nämlich noch nicht geblick..

SCons zieht sich den Pfad zum Visual C++ Compiler normalerweise aus den Umgebungsvariablen. Funktioniert denn dies nicht?