Portable Programmierung mit C und Makefiles

@Yamagi Danke für info! Muss ich mir ansehen. Statisch linken ist immer gut! Mit dynamischem linken habe ich mich nämlich noch nicht beschäftig, da muss ich mich erst noch reindenken. ;) Mir geht es im übrigen auch um Ästhetik und ich muss mir erst einmal ansehen wie fltk sich diesbezgl. macht. Ich weiss: Ist Programmierern ist das meist egal! :rolleyes:

NB: Dein os-autodetct funktioniert so unter msys2 nicht. Ist aber egal, ich finde platform=<?> eh besser. Die Lua-Leute machen das so und die haben reichlich Erfahrung mit solchen Sachen. So kann ich unter mys2 sowohl win und wohl auch linux settings ausprobieren.
 
rubricanis said:
@ ralli: Wie gesagt, muss ich mir anschauen. Verwendet fltk die nativen windows widgets?
Click to expand...
Ist schon etwas länger her, als ich mich mit FLTK beschäftigte. Ich habe es aber unter Linux und FreeBSD ausprobiert und da war GTK Look voreingestellt. Und ich glaube, das FLTK ein eigenes Widget Set mitbringt. Ist bestimmt auf der Homepage ersichtlich. Es kursiert im Netz eine Einführung für die Arbeit mit FLUID in deutsch und gut gemacht, weil es den Einstieg erleichtert. Mußte mal ergoogeln.
 
Es spricht eine ganze Menge für IUP, dies insbesondere da es vergleichsweise klein ist, in C geschrieben und ich einen Lua interpreter embedded habe. Auf GTK+ bin ich nur gekommen weil ich dessen Look & Feel mag, es in C geschrieben ist und ich einen Artikel gelesen habe dass die Implementation unter mysy2 auch relativ leicht zu machen ist. Bis ich dahin komme muss allerdings noch einiges an Grundlagenarbeit gemacht werden. Aber man sollte schon wissen in welche Richtung das einmal gehen soll. Ich denke ohne GUI kommt man heute in vielen Fällen nicht aus, auch wenn man meist die cmdline benutzt. Den Vergleich zwischen Racket und Chicken scheme fand ich diesbezgl. interessant.
 
GUI-Toolkits sind auch definitiv sehr Geschmackssache, über die es nicht lohnt sich zu streiten. Oft ist man sowieso durch die Umgebung an ein Toolkit gebunden. Wenn man wirklich platformunabhängig sein will, ist Qt auch definitiv einen Blick wert. Aber das ist dann auch gleich wieder C++ und in Sachen Umfang ein absolutes Monster.

rubricanis said:
NB: Dein os-autodetct funktioniert so unter msys2 nicht. Ist aber egal, ich finde platform=<?> eh besser. Die Lua-Leute machen das so und die haben reichlich Erfahrung mit solchen Sachen. So kann ich unter mys2 sowohl win und wohl auch linux settings ausprobieren.
Click to expand...
Hmm... Dafür hatte ich einen Sonderfall:
Code: 
ifneq (,$(findstring MINGW,$(OSTYPE)))
OSTYPE := Windows
endif
Ein ganzes Makefile mit dem Gedöns ist übrigens hier: https://github.com/yquake2/yquake2/blob/master/Makefile Ich erhebe aber nicht den Anspruch, dass mein Weg der einzig wahre Weg ist. Einer der Vor- und Nachteile von make ist, dass man sich ausleben kann.
 
Yamagi said:
GUI-Toolkits sind auch definitiv sehr Geschmackssache, über die es nicht lohnt sich zu streiten.
Click to expand...
Nöö, streiten nicht, aber es gibt schon guten und weniger guten Geschmack, um von schlechtem überhaupt nicht zu reden! :) Aber es gibt auch einige objektive Kriterien die meist vom Einsatzbereich bestimmt werden; Größe, längerfristige und austreichende professionelle Unterstützung , Entwicklungsperspektive u.Ä. mehr.

Für mich spielt z.Z. ein vorhandenes Lua-Interface und die Implementierungssprache eine Rolle. C ist eben meine aktuelle Liebe und wie immer das mit der Liebe ist, gibt es eben im Moment nichts anderes! :) Und Lua ist wie eine alte, halb vergessene, gute Freundin...

Einer der Vor- und Nachteile von make ist, dass man sich ausleben kann.
Click to expand...
Ich bin eher ein Freund von Restriktionen, aber OK, die kann ich mir auch selbst auferlegen. Ist bei make allerdings nicht so einfach...
 
Ich habe einen Feler bei dem ich (trotz langem suchen) einfach nicht weiter komme. Vielleicht kann mir jemand auf die Sprünge helfen.

Mein Programm besteht z.Z. aus einer statischen lib und dem main-programm das an die lib gelinkt werden soll. Wenn ich das Programm mit gcc kompiliere und linke funktioniert das ohne Probleme. Mit clang bekomme ich allerdings folgenden Fehler:
Code: 
src/exe/main.o: In function `main':
src/exe/main.c:(.text+0x17): undefined reference to `get_home'
collect2: error: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/exe.make:12: exe] Error 1
make: *** [GNUmakefile:62: exe] Error 2
Klar, 'get_home' ist in der lib. Mein etwas vereinfachtes und modifiziertes Makefile:
Code: 
#include pre.make -- da werden u.A. folgende flags in gesetzt:
LF := -lpthread -lm
CC := $(compiler) $(std)  -Wall -Werror -Wno-unused -pthread

BIN := $(BIN_DIR)/xx)
LIB := $(LIB_DIR)/libxx.a
SRC := $(wildcard $(SRC_DIR)/*.c)
OBJ := $(SRC:%.c=%$.o)

exe: $(OBJ)
    @$(CC) -o $(BIN) $(OBJ) $(LIB) $(LF)

$(SRC_DIR)/%.o: $(SRC_DIR)/%.c
    @$(CC)  -c $< -o $@
Ich weiß nicht so recht wie ich das angehen kann. Die verbose option schüttet einen mit langen Aufruflisten voll. Die ld-flags verstehe ich nicht wirklich und davon gibt es ja eine unendlich Anzahl. Gibt es da irgendwelche tools oder flags mit denen man das transparenter machen kann?
 
Ich war im Urlaub, daher die späte Antwort... Ich würde gerne mal den Linker-Aufruf sehen. Also einmal das @ vor '@$(CC) -o $(BIN) $(OBJ) $(LIB) $(LF)' raus und dann die Ausgabe davon.
 
Ich bin gerade dabei das makefile wg. einer lib mit recht speziellen Anforderunge zu ändern. Wenn ich fertig bin, poste ich es hier. Kann ein paar Tage dauern da z.Z. anderes Vorrang hat.
 
Ich habe das mal rekonstruiert. Sind inzwischen natürlich mehr Link-Fehler bei clang. Zum Verständnis: Ich benutze 3 Makefiles:
(1) das Haupt-Makefile. Das übergibt einige Variable (cc, std, self [der Name], platform [z.Z. windows/unix], mode) an das
(2) lib/exe makefile. Das includiert ein
(3) pre.make das für alle libs/exe gleich ist.
Die Variablen werden z.T in (2), z.T. in (3) ausgewertet. Die Pfade sind alle vom top-level, also keine rekursiven makefiles.

Hier das pre.make:
Code: 
ifeq ($(platform), windows)
    DF += -DXXX_WINDOWS
else
    DF += -DXXX_UNIX
endif

# directories
BASE_DIR := xxx
LIB_DIR := lib
SRC_DIR := src/$(self)
INC_DIR := $(BASE_DIR )/inc
DYN_DIR := $(BASE_DIR )/lib
BIN_DIR := $(BASE_DIR )/bin

# utils
AR  := ar rcu
CP  := cp -p

# include flag
IF := -I$(INC_DIR)

# link flags
LF := -lm -lpthread

# ------ config --------
CC := $(cc) $(std)  -Wall -Werror -Wno-unused -pthread

ifneq ($(platform), windows)
    CC += -fPIC
endif

ifeq ($(mode), debug)
    CF += -g -og -ggdb -DDEBUG
    EXT := -dbg
else ifeq ($(mode), release)
    CF += -o2 -DNDEBUG
else
    CF += -o1 -DNDEBUG
endif

CC += $(CF)
Und hier das exe.make
Code: 
include pre.make

BIN := $(BIN_DIR)/$(self)
LIB := $(LIB_DIR)/libxxx.a
SRC := $(wildcard $(SRC_DIR)/*.c)
OBJ := $(SRC:%.c=%$(EXT).o)

$(self): $(OBJ)
    @$(CC) $(IF) $(DF) -o $(BIN) $(OBJ) $(LIB) $(LF)

$(SRC_DIR)/%$(EXT).o: $(SRC_DIR)/%.c
    @$(CC) $(IF) $(DF) -c $< -o $@
Ich vermute dass clang mit einem anderen compile- und/oder link-format operiert was vermutlich durch ein flag verändert werden kann. Habe ich aber noch nicht weiter verfolgen können. Dann müßte in pre.make so etwas stehen wie
Code: 
ifeq ($(cc), clang)
   ifeq ($platform), windows)
      CC += ?
      LF += ?
   endif
endif
 
@Yamagi : Ich denke ich verzichte unter windows auf clang. Es ist eh notwendig msys2 zu installieren und die damit verbundenen tools. Das clang hatte ich auch einfach in mysy2 installiert und ist wahrscheinlich nicht an mingw angepaßt. Insofern erübrigt sich das alles unter windows. Auf clang werde ich unter unix wieder zurückkommen. Das eigentliche Problem ist ja windows...
 
You must log in or register to reply here.
Back
Top