aboutsummaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2021-09-08 06:48:58 -0300
committerEuAndreh <eu@euandre.org>2021-09-08 07:01:48 -0300
commitb03b35d768a60c81b28138e2f4f5cd9a0a5ca721 (patch)
treeca3f079e87b9085fe429af330b9698292221d351 /Makefile
parentTODOs.md: Add #question-ab994373-9c09-c4f9-07cf-962f64443231 (diff)
downloadgistatic-b03b35d768a60c81b28138e2f4f5cd9a0a5ca721.tar.gz
gistatic-b03b35d768a60c81b28138e2f4f5cd9a0a5ca721.tar.xz
src/gistatic.in: Initial sh version
I got a bit frustrated that libgit2 didn't offer an API or "git archive" commands. I started implementing generating tarballs from scratch in src/tar.c and I'm quite liking it: the specification is very small, and the code can be very simple, since all I'm doing is writing fresh tarballs, and not reading or updating them. However I felt a bit locked-in to libgit2 itself, and what a detour from my original goal that is, and the question "what should libgit2 provide" came up to my mind. This made me realize that libgit2 is playing catch-up with Git itself, for as long as Git doesn't explicit has an explicit API, a standard, a public version of its internal libgit.a, or something like that. In fact, I'm locked in to Git, even. So even though a C version would probably be much faster, it wouldn't really have less dependencies, and that's what I'm actually optimising for: having the software be as portable as possible. On that front, C is unbeatable with sh as a close second. But the extreme portability of C aren't being fully exploited here: libgit2 does depend on non-POSIX things like CMake (and quick grep even shows references to -D_GNU_SOURCE!!), and Git's Makefile itself isn't POSIX at all. The point is: by depending on either Git or libgit2, I'm already loosing many selling points of writing the software in C, and sh becomes much more attractive. Had existed a common DVCS interface that could make me decouple gistatic from Git somehow I would insist a bit more in C, but now I'm switching to sh. The fact that I was able to get further with sh in one sitting than I did with C shows that a) I'm a bit less fluent in C than I would like (at least for now ^^) and b) that it is actually much simpler to do. I am quite satisfied with the quality of C code that I got so far. The error handling and propagation is pretty robust, and the implementation is very disciplined. I did most of the development with Valgrind, and other sanitizers would help even further, with some fuzzers on top.
Diffstat (limited to 'Makefile')
-rw-r--r--Makefile5
1 files changed, 3 insertions, 2 deletions
diff --git a/Makefile b/Makefile
index 5aa3159..48a52ef 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,7 @@ LDLIBS = -lgit2
-e 's:@DATE@:$(DATE):g' \
-e 's:@NAME@:$(NAME):g' \
< $< > $@
+ if [ -x $< ]; then chmod +x $@; fi
.c.o:
$(CC) $(CFLAGS) -o $@ -c $<
@@ -44,7 +45,7 @@ all-objects = $(lib-objects) src/main.o
t-objects = $(sources:.c=.to) src/tests-lib.to src/main.to
-all: libgistatic.a gistatic $(manpages)
+all: libgistatic.a gistatic src/gistatic $(manpages)
libgistatic.a: $(lib-objects)
$(AR) $(ARFLAGS) $@ $(lib-objects)
@@ -85,7 +86,7 @@ clean:
rm -rf \
public/ $(manpages) README.*.md CHANGELOG.*.md messages.mo \
vgcore.* tmp/ src/config.h $(all-objects) $(t-objects) \
- libgistatic.a gistatic gistatic-tests \
+ libgistatic.a gistatic gistatic-tests src/gistatic \
tests/resources/repositories/repo-1/.git \
tests/resources/repositories/repo-2/.git