Παιχνίδι 2048 σε C

[imitheos]

Επειδή βλέπω ότι σου φαίνονται λίγες οι υπό-εντολές του git και δεν έχεις χορτάσει, να θυμηθώ να γράψω για το squashing όταν τα κάνει merge (βασικά και τώρα μπορώ αν χρησιμοποιήσω το δικό σου repo αλλά βαριέμαι τώρα )

Πιθανώς να μην ενδιαφέρει κανέναν αλλά ας γράψω για το squashing

 

% git log --reverse --oneline 9085ec5..               
0eae7a8 Removed gtk2_replayer from master
64987e2 con_color: Remove compiler warnings in win32 - (int)GetLastError()
c1b73d2 Merge pull request #17 from migf1/master
d195dfe Ta neyra moy
aa4aad3 Ta neyra moy #2
b795e6b test
9fb6209 Test 2
361b108 Test again
c40ab0f Add _bak and lang
2df5bb8 Added .session and .exe
c8d4767 Ignore .session and .exe
e1866da Ignore _bak and lang
3627a15 Add gui/_bak and gui/_org
1a053f6 Ignore gui/_bak and gui/_org
b6b73a0 Added
04cd563 Delete (keep local)

Τα παραπάνω είναι τα τελευταία commits που έχουν γίνει (γίνεται λίγο χαμός λόγω του τρόπου που δουλεύει το github και των κακών merge που έχουν γίνει).

 

[intro]

Όπως έχουμε ξαναπεί σε παλαιότερο μήνυμα, το subversion είναι centralized VCS δηλαδή οποιαδήποτε εργασία εκτελούμε χρειάζεται να επικοινωνήσει με τον server. Έτσι πολλές εργασίες γίνονται με πολύ μικρή ταχύτητα ειδικά όταν βρισκόμαστε στο δρόμο με χάλια ασύρματα δίκτυα. Επίσης μπορεί να βρισκόμαστε σε αεροπλάνο ή κάπου χωρίς δίκτυο οπότε να μην έχουμε πρόσβαση στον server. Αυτό είχε ως αποτέλεσμα να γίνει κοινή πρακτική το μάζεμα πολλών αλλαγών και η καταχώριση τους με την μία σε ένα commit. Κάποιος θα επιχειρηματολογήσει ότι αυτό δεν είναι πρόβλημα του SVN γιατί δεν αναγκάζει κανέναν να κάνει μεγάλα commits αλλά φταίει η τεμπελιά πολλών developer. Όταν όμως κάθε commit θέλει 25 δευτερόλεπτα, είναι λίγο δύσκολο να μην θέλεις να το αποφύγεις. Όπως και να έχει, το θέμα είναι ότι πολλές φορές βλέπαμε τεράστια commits σε CVS / SVN.

 

Στα DVCS όπως το git όλα γίνονται τοπικά με τεράστια ταχύτητα οπότε δεν έχουμε το παραπάνω πρόβλημα και έτσι προάγεται ένας διαφορετικός τρόπος δουλειάς με πολλά μικρά commits. Όσο μικρό και να είναι αυτό που άλλαξες κάνε το commit τώρα που θυμάσαι γιατί το έκανες και μπορείς να το περιγράψεις πολύ καλά στο commit message.

 

Γιατί τα είπα τώρα αυτά ?

 

Αυτό που μας νοιάζει πάντα είναι να έχουμε την καλύτερη ιστορία που μπορούμε. Έτσι κατά την διάρκεια της ανάπτυξης είναι καλό να έχουμε μικρά αυτοτελή commits που να διορθώνουν ένα μόνο πράγμα. Στο τέλος όμως της ανάπτυξης κάποια στοιχεία χάνουν την αξία τους. Για παράδειγμα δεν ενδιαφέρει κανέναν να δει ότι έγιναν 35 commits που διορθώνουν τυπογραφικά λάθη μία λέξη το καθένα. Ένα commit που να περιέχει όλα τα fixes του αρκεί. Εκτός από άσχημα, μπορεί να δυσκολεύουν το blame ή να κάνουν δύσκολο το bisection γιατί μπορεί το tree όπως αντικατοπτρίζεται στο commit X να μην γίνεται compile (αλλά στο Χ + 1 να γίνεται compile) και έτσι να δυσκολεύει η δουλειά του χρήστη που προσπαθεί να κάνει bisect.

 

Εν προκειμένω λοιπόν, δεν προσφέρουν τίποτα στην ιστορία του project commits τύπου "τα νεύρα μου", "test 2". Εμένα σαν developer με ενδιαφέρει α) ότι ο τάδε developer ανέπτυξε το Χ feature β) το έκανε γιατί ήταν απαραίτητο για την επίλυση του Ψ προβλήματος και γ) ότι το ανέπτυξε χρησιμοποιώντας τον Κ αλγόριθμο γιατί ήταν ο βέλτιστος ανάμεσα στους Κ, Λ, Μ.

 

Αν όμως έκανε 35 test commits, του έσπασαν τα νεύρα και θυσίασε ένα πρόβατο στον Ιμχοτέπ δεν αφορά κανέναν.

 

Για αυτό ερχόμαστε στο τέλος της ανάπτυξης του branch και ενώνουμε όλα τα άχρηστα commits. Αυτό γίνεται με την χρήση της interactive rebase που περιγράψαμε και σε προηγούμενο μήνυμα.

 

Για να χρησιμοποιήσουμε την interactive rebase είχαμε πει ότι πρέπει να της δώσουμε το commit που είναι parent του πρώτου commit που θέλουμε να διορθώσουμε. Για να μην ψάχνουμε ποιο commit είναι θα χρησιμοποιήσουμε τον συμβολισμό ^. Το πρώτο commit που θέλουμε να πειράξουμε είναι το "τα νεύρα μου" οπότε θα δώσουμε d195dfe^.

 

% git rebase --interactive d195dfe^
pick d195dfe Ta neyra moy
pick aa4aad3 Ta neyra moy #2
pick 361b108 Test again
pick c40ab0f Add _bak and lang
pick 2df5bb8 Added .session and .exe
pick c8d4767 Ignore .session and .exe
pick e1866da Ignore _bak and lang
pick 3627a15 Add gui/_bak and gui/_org
pick 1a053f6 Ignore gui/_bak and gui/_org
pick b6b73a0 Added
pick 04cd563 Delete (keep local)

# Rebase 9085ec5..04cd563 onto 9085ec5
#
# Commands:
#  p, pick = use commit
#  s, squash = use commit, but meld into previous commit

Μας ανοίγει τον editor και βλέπουμε την παραπάνω εικόνα. Όπως μας εξηγεί το βοηθητικό κείμενο, αρκεί να αλλάξουμε το pick σε squash σε όλα τα commits εκτός από το πρώτο. Αφού το κάνουμε και εκτελέσουμε την rebase, θα μας ζητήσει να συντάξουμε ένα νέο commit μήνυμα στο οποίο γράφουμε τι αλλαγές επιτελεί το συγκεκριμένο commit.

 

% git log --reverse --oneline 9085ec5..
8be3f0c Add _bak and lang and gui and others

Όπως βλέπουμε, όλο το κατεβατό των άθλιων commit έχει γίνει ένα όμορφο commit. Τώρα μπορούμε να κάνουμε push το branch για να το δούνε οι υπόλοιποι developers και να μας πουν τη γνώμη τους.

 

Όλα τα παραπάνω commits βέβαια δεν επιτελούσαν το ίδιο σκοπό και δεν έπρεπε να τα ενώσω όλα σε ένα. Το σωστό θα ήταν να τα χωρίσω σε ομάδες και να δημιουργήσω 3-4 commits αντί για το ένα που δημιούργησα αλλά είναι παράδειγμα και δεν πειράζει. Αν ήταν μια κανονική rebase θα κοιτούσα να μην το παρακάνω και από εκεί που είχα πολλά άχρηστα commits να μην καταλήξω στο άλλο άκρο του να χάσω πολύτιμη ιστορία και να έχω τεράστια commits όπως στο SVN.

Επεξ/σία 15 Αυγούστου 2014 από imitheos

[migf1]

Ωραίος!

 

 

 

Αν πω όμως ότι έχω αυτή τη στιγμή το μυαλό να το διαβάσω αναλυτικά, ψέμματα θα πω

Σίγουρα θα το "μελετήσω" όμως στην 1η ευκαιρία... τώρα σκέφτομαι άλλα πράγματα... παραλίες, ρακέτες, τρυφερές στιγμές με το έτερον ήμισυ, (κρυφές ματιές στα έτερα ήμισυ άλλων ), ταβερνάκια, ουζάκια, κλπ... και επίσης, σιγά μην έχω ασχοληθεί με τα σχόλια του player

 

 

[migf1]

Γύρισα, αλλά για κάποιον λόγο έχω μια άρνηση να ασχοληθώ με το πρότζεκτ. Υποθέτω θα μου περάσει σε μερικές μέρες (μόλις προσαρμοστώ ξανά στην ρουτίνα της πόλης ).

[Pantelwolf]

https://github.com/mydzor/bash2048/blob/master/bash2048.sh

[geomagas]

Γύρισα, αλλά για κάποιον λόγο έχω μια άρνηση να ασχοληθώ με το πρότζεκτ. Υποθέτω θα μου περάσει σε μερικές μέρες (μόλις προσαρμοστώ ξανά στην ρουτίνα της πόλης ).

 

Κι εδώ τα ίδια... Άρνηση γενικότερα. Σέρνομαι...

 

Καταραμένες διακοπές! Να τις καταργήσουμε, να μην έχουμε τον μπελά της προσαρμογής!

[imitheos]

Γύρισα, αλλά για κάποιον λόγο έχω μια άρνηση να ασχοληθώ με το πρότζεκτ. Υποθέτω θα μου περάσει σε μερικές μέρες (μόλις προσαρμοστώ ξανά στην ρουτίνα της πόλης ).

Κι εδώ τα ίδια... Άρνηση γενικότερα. Σέρνομαι...

 

Καταραμένες διακοπές! Να τις καταργήσουμε, να μην έχουμε τον μπελά της προσαρμογής!

Ό,τι μπάνιο κάνατε και ό,τι μάτι πήρατε φτάνει. Γρήγορα τα κεφάλια μέσα και δουλειά. Να βλέπω να γίνονται merges

 

[offtopic]

Οι διακοπές μια χαρά είναι. Αυτό που μου τη δίνει εμένα είναι οι αργίες. Κάθε 2 μέρες είναι αργία και κάθε ΣΚ είναι τριήμερο. Αν καταργούσαμε τις άχρηστες εθνικές - θρησκευτικές αργίες (δηλαδή το 80% αυτών) θα με ευχαριστούσε.

[geomagas]

Ό,τι μπάνιο κάνατε και ό,τι μάτι πήρατε φτάνει. Γρήγορα τα κεφάλια μέσα και δουλειά. Να βλέπω να γίνονται merges

 

[offtopic]

Οι διακοπές μια χαρά είναι. Αυτό που μου τη δίνει εμένα είναι οι αργίες. Κάθε 2 μέρες είναι αργία και κάθε ΣΚ είναι τριήμερο. Αν καταργούσαμε τις άχρηστες εθνικές - θρησκευτικές αργίες (δηλαδή το 80% αυτών) θα με ευχαριστούσε.

 

Θ' αστειεύεσαι βέβαια...

[migf1]

Χε χε... εγώ πάντως κατά 99.99% μεσοβδόμαδα θα την κοπανήσω πάλι

 

EDIT:

 

@Pantelwolf: Λιτό και αξιοπρεπές, αν και πολύ primitive.

[paredwse]

Έχουν ήδη διαγραφεί ήδη επτά (7) offtopic μηνύματα. 

Καλό θα ήταν να μην συνεχιστεί αυτό.

 

My 2 cents... 

[petran_18]

Kαλημέρα παιδιά και συχγαρητήρια για την δουλειά που κάνατε με το παιχνίδι  μου άρεσε πολύ. Μάλιστα μου άρεσε τόσο πολύ, που μιας και κουτσά προσπαθώ να μάθω για ebuilds στο gentoo, αποφάσισα να κάνω και ενα για το (το προηγούμενο ήταν για το Ultimate++) 2048cc και αν είναι αξιοπρεπές και δουλεύει, ίσως το ανεβάσουμε κιόλας να μάθουν το παιχνίδι σας και άλλοι και να εγκαθίσταται "νόμιμα" απο τον PM. Για όσους δεν ξέρουν τι είναι ένα ebuild, να αναφέρω σύντομα, οτι είναι μικρά script αρχεια της Bash και της Python και χρησιμοποιούνται απο τον PMS του gentoo (portage) για να κατεβάσουν, να κάνουν config και τέλος να μεταγλωττίσουν και να εγκαταστήσουν το εν λόγω πακέτο.

 

Αντιμετώπισα όμως κάποιες δυσκολίες πέρα απο την δομή και την σύνταξη του ebuild και αυτές έχουν να κάνουν με το οτι το portage κανει compile τα πακέτα με βάση κάποιον αυτοματισμό (makefile/CMakeLists.txt) που όμως απουσιάζει απο το repository στο git. Έγραψα λοιπόν ενα Makefile, που αντιγράφεται την κατάλληλη στιγμή απο κάποιο καταλογο μου. Φυσικά το ορθό θα ήταν να κατεβαίνει μαζι με τον κώδικα για όλους τους πιθανούς χρήστες/παίκτες του παιχνιδιού στην Gentoo.

 

Aν έχετε την θέληση για κάτι τέτοιο, έχω έτοιμα 2 ebuild και το Makefile, είναι ανεβασμένα στο adslgr.com και μπορώ (αν επιτρέπεται - δεν ξέρω) να δώσω λινκ, γιατί γράφω απο άλλο pc και δεν τα έχω. Tο makefile και τα ebuilds δουλεύουν αλλά δεν έχω δεύτερο Gentoo, να το διασταυρώσω, δυστυχώς. Εμπρός beta-testers μου     Πλάκα κάνω φυσικά.

 

Τέλος να πω οτι δεν είχα ξαναγράψει Makefile ουτε ebuild (καλα ενα - δυο) και είναι πιθανό να καραφλιάσετε. Συνίσταται εντόνως αγορά περούκας    .

 

Περιμένω απάντηση απο κάποιον Mod για το link σε άλλο φόρουμ και αν είναι επιτρεπτό.

[migf1]

Πέτρο σε ευχαριστώ που τελικά το δημοσίευσες εδώ!

 

Όπως σου είπα και στο e-mail, τόσο ο geomagas όσο και ο imitheos (και σίγουρα πολλοί ακόμα) παίζουν στα δάχτυλα τα περί Linux πολύ (μα πάρα πολύ) καλύτερα από ότι εγώ. Εμένα το κύριο λειτουργικό μου είναι τα Windows, κι από Linux ξέρω μονάχα ότι μου είναι απολύτως απαραίτητο για να κάνω την εκάστοτε δουλειά μου (όταν την κάνω, μετά επιστρέφω πάλι στα Windows, με αποτέλεσμα τα μισά του Linux να τα ξεχνάω, οπότε καταφεύγω και πάλι σε man pages και google όταν τα ξανά χρειαστώ).

 

Όπως επίσης σου έγραψα και στο email, παρόλο που αρχικά ήθελα να αποφύγουμε τα platform-specific πράγματα στο git του παιχνιδιού (εξού και η απουσία makefiles), τελικά νομίζω δεν είναι κακή ιδέα να βάλουμε και platform-specific utilities στο git, αρκεί να τα μαρκάρουμε ευκρινώς ως τέτοια (ενδεχομένως σε ξεχωριστούς φακέλους, δεν ξέρω... ακόμα καλύτερη φάση θα ήταν να υπάρχουν και platform specific binaries, τόσο για το game όσο και για τον/τους replayers).

 

Επειδή όμως εγώ δεν έχω την *nix-άτη ευχέρεια, προτείνω να το χειριστούν είτε ο geomagas είτε ο imitheos, είτε και οι 2, είτε όποιος άλλος γνωρίζει και θέλει

 

 

ΥΓ. Εδώ και κάνα 15-θήμερο δεν έχω και στημένο Linux σε εύκολα προσβάσιμο από εμένα μηχανάκι... σκοπεύω να στήσω ξανά ένα με dual-boot, γιατί το προηγούμενο μας άφησε χρόνους... το πότε ακριβώς, δεν το γνωρίζω ακόμα )

[imitheos]

CC=gcc
CFLAGS+= -std=c99 -Wall
LDFLAGS+= 
PREFIX = $(DESTDIR)/usr/local
BINDIR = $(PREFIX)/bin
OBJ = board.o common.o gs.o main.o mvhist.o my.o tui.o tui_skin.o
CFILES = $(shell ls ./*.c)
all = 2048cc

all: 
    $(CC) -c $(CFILES) $(CFLAGS)
    $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ) -o $(all)  

install:
    
    install  -D -v $(all) $(BINDIR)/

uninstall:
    rm -v $(BINDIR)/$(all)

clean:
    rm -v $(all) $(OBJ)

Από ό,τι βλέπω, το Makefile είναι το παραπάνω. Ας δούμε κάποια τμήματα.

 

 

CC=gcc

% export CC=clang
% make
gcc -std=c99 -Wall -c ./board.c ./common.c ./gs.c ./main.c ./mvhist.c ./my.c ./tui.c

% sed -i "s/^CC=/CC?=/g" Makefile 
% make
clang -std=c99 -Wall -c ./board.c ./common.c ./gs.c ./main.c ./mvhist.c ./my.c ./tui.c 

Το = σημαίνει απευθείας ανάθεση οπότε υπερνικάει οτιδήποτε επιλογή έχει θέσει ο χρήστης. Όπως βλέπεις ενώ έχω ορίσει ότι θέλω clang για CC, το make το γειώνει και τρέχει gcc. Για αυτό αν οπωσδήποτε πρέπει να δηλώσεις CC είθισται να μπαίνει ως CC?= που σημαίνει ανάθεση αν και μόνο αν η μεταβλητή δεν υφίσταται ήδη. Μετά την αλλαγή σε CC?= που έκανα με τη χρήση του sed, το make τιμά την επιλογή μου και τρέχει τον clang.

 

CFLAGS+= -std=c99 -Wall

Εδώ το έβαλες με += οπότε δεν υπάρχει το προηγούμενο πρόβλημα και οι επιλογές του χρήστη θα τηρηθούν αλλά μπορεί να δημιουργηθεί ένα άλλο πρόβλημα.

% export CFLAGS="-Wstrict-overflow=2"
% make
cc -Wstrict-overflow=2 -std=c99 -Wall -c ./board.c ./common.c ./gs.c ./main.c ./mvhist.c ./my.c ./tui.c ./tui_skin.c 

Δες το παραπάνω παράδειγμα. Εγώ έχω ορίσει την επιλογή strict-overflow με τιμή 2 και σε αυτήν προστίθενται οι δικές σου CFLAGS μέσα στις οποίες υπάρχει και η Wall η οποία όμως ενεργοποιεί την strict-overflow=1 οπότε η δική μου επιλογή θα είναι σαν να μην υπήρξε ποτέ. Για αυτό πολλές φορές βλέπεις να προτείνεται η Wall να είναι η πρώτη επιλογή. Αυτό είχε δηλωθεί ως bug στον gcc πριν πολύ καιρό και ίσως να έχει φτιαχτεί οπότε να μην υφίσταται το πρόβλημα που περιέγραψα. Δεν θυμάμαι τι έχει γίνει.

 

OBJ = board.o common.o gs.o main.o mvhist.o my.o tui.o tui_skin.o
CFILES = $(shell ls ./*.c)

Αν δεν είσαι υποχρεωμένος να το κάνεις, μην χρησιμοποιείς globs, shells, vpaths, whatever. Εφόσον έχεις ορίσει χειροκίνητα τα object τα οποία απαρτίζουν το project σου, γιατί μετά να μπλέξεις με shell, ls και δεν συμμαζεύεται ?

 

CFILES = $(OBJ:.o=.c)

Το παραπάνω λέει πάρε την μεταβλητή OBJ και όπου βλέπεις .o μετέτρεψε το σε .c οπότε έχεις αυτό που θέλεις χωρίς να χρειάζεσαι ls ή ποιος ξέρει τι.

 

all = 2048cc

all: 
    $(CC) -c $(CFILES) $(CFLAGS)
    $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ) -o $(all)  

Εδώ δεν ξέρω γιατί το έχεις έτσι. Ένα πράγμα που χρησιμοποιώ συχνά είναι οι γενικοί κανόνες ώστε να μην χρειάζεται να γράψω πολλά πράγματα. Το παραπάνω εγώ θα το έγραφα ως εξής:

 

PROG=2048cc

.PHONY: all install clean
all: $(PROG)

$(PROG): $(OBJ)

%.o: %.c
    $(CC) $(CFLAGS) -c -o $@ $^

%:
    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

Με το παραπάνω δεν χρειάζεσαι καθόλου την μεταβλητή CFILES που βελτιώσαμε πριν.

 

Ας δούμε την διαδικασία που ακολουθείται. Οι σκοποί all install clean δηλώνονται ως PHONY ότι δηλαδή τα ονόματά τους είναι πλασματικά και δεν μιλάμε για αρχεία (δοκίμασε να δημιουργήσεις ένα αρχείο all ή clean και χωρίς το phony θα δεις ότι έχεις πρόβλημα).

 

Το make από την μάνα του θα προσπαθήσει να φτιάξει τον πρώτο σκοπό που βρίσκει οπότε τον σκοπό all ο οποίος έχει εξαρτήσεις το αρχείο 2048cc. Έτσι ψάχνει να δει πως θα φτιάξει το 2048cc. Από τον κανόνα % ξέρει ότι θα φτιάξει χρησιμοποιώντας την τάδε εντολή που έχουμε δηλώσει. Το $@ σημαίνει το όνομα του σκοπού οπότε είναι το 2048 ενώ το $^ σημαίνει τις εξαρτήσεις. Ποιες είναι οι εξαρτήσεις του ? Βλέπουμε ότι το PROG έχει εξαρτήσεις τα OBJ.

 

Άρα το 2048cc θα γίνει compile χρησιμοποιώντας την εντολή "τάδε -o 2048cc board.o common.o κτλ"

 

Τώρα πρέπει να βρει πως να φτιάξει το τάδε.ο αρχείο. Εδώ έρχεται ο προηγούμενος κανόνας που λέει ότι το εκάστοτε .o αρχείο έχει ως εξάρτηση το αρχείο με ίδιο όνομα και επέκταση .c οπότε η εντολή θα είναι "τάδε -c -ο common.o common.c"

 

Η παραπάνω μορφή έχει το ίδιο αποτέλεσμα με τη δική σου χωρίς όμως να χρειάζεσαι εξωτερικές εντολές και περιττές μεταβλητές. Επίσης έχει το καλό ότι αν στο μέλλον αλλάξει κάτι στο tree σου, απλά θα πας να βάλεις το νέο αρχείο στο OBJ χωρίς να πειράξεις τίποτα άλλο.

 

Φυσικά κάποιος άλλος μπορεί να γράψει μια εντελώς διαφορετική μορφή Makefile που να παίξει εξίσου καλά ή καλύτερα.

[geomagas]

@migf1: ...Είδες πως παίζουν το linux στα δάχτυλα;!;!; Αυτά είναι! Για μένα, μπορείς να το πεις μόνο συμβολικά, για το γεγονός ότι χρησιμοποιώ ...πληκτρολόγιο!

 

@petran_18: Καλωσήρθες στην ομήγυρη και γενικότερα στο forum!

 

@all: Χαίρομαι που αναβίωσε το thread, ευκαιρία είναι μόλις ξε-πήξουμε μερικοί-μερικοί να ξανασχοληθούμε! (είπε στον εαυτό του)

[petran_18]

Παρακαλώ migf1

 

@imitheos ευχαριστώ θα το ξαναγράψω για να το εμπεδώσω.

 

 

@petran_18: Καλωσήρθες στην ομήγυρη και γενικότερα στο forum!

 

:-D  Thanks

[petran_18]

CC?= gcc
CFLAGS+= -Wall -std=c99
LDFLAGS+= 
PREFIX = $(DESTDIR)/usr/local
BINDIR = $(PREFIX)/bin

OBJ = board.o common.o gs.o main.o mvhist.o my.o tui.o tui_skin.o

PROG=2048cc

.PHONY: all install clean
all: $(PROG)

$(PROG): $(OBJ)

%.o: %.c
	$(CC) $(CFLAGS) -c -o $@ $^

%:
	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

install:
	install  -D -v $(PROG) $(BINDIR)/

uninstall:
	rm -v $(BINDIR)/$(PROG)

clean:
	rm -v $(PROG) $(OBJ)

Console output

make
cc -Wall -std=c99 -c -o board.o board.c
cc -Wall -std=c99 -c -o common.o common.c
cc -Wall -std=c99 -c -o gs.o gs.c
cc -Wall -std=c99 -c -o main.o main.c
cc -Wall -std=c99 -c -o mvhist.o mvhist.c
cc -Wall -std=c99 -c -o my.o my.c
my.c: In function ‘my_sleep_msecs’:
my.c:432:3: προειδοποίηση: implicit declaration of function ‘usleep’ [-Wimplicit-function-declaration]
   if ( -1 == usleep(usecs) ) {
   ^
cc -Wall -std=c99 -c -o tui.o tui.c
cc -Wall -std=c99 -c -o tui_skin.o tui_skin.c
cc -Wall -std=c99  -o 2048cc board.o common.o gs.o main.o mvhist.o my.o tui.o tui_skin.o

Να ρωτήσω κάτι σχετικά με τον GCC. Γιατί απλά δεν του λέμε να βγάλει τα object files με την -c μονo Πχ gcc -c main.c / όλα τα αλλα .c και μετά όπως ήδη το κάνουμε μονο gcc -ο. Κάτι είχα κάνει και γκρίνιαξε ότι η -c με την -ο είναι ασύμβατες αλλα δεν θυμάμαι. Τέλοσπαντων, δεν έχει και σημασία εγκυκλοπαιδική ερώτηση είναι.