pk
/
slstatus
mirror of https://github.com/pikami/slstatus.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
slstatus/Makefile

88 lines
2.9 KiB
Makefile
Raw Normal View History

Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
# See LICENSE file for copyright and license details
Refactor build system
2017-08-10 20:32:10 +01:00
# slstatus - suckless status monitor
.POSIX:
what kind of weed is that?
2016-09-05 00:17:30 +01:00
include config.mk
Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
REQ = util
COM =\
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
components/battery\
components/cpu\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/datetime\
components/disk\
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
components/entropy\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/hostname\
components/ip\
components/kernel_release\
components/keyboard_indicators\
Add keymap component Adding a new keymap component that will indicate the current keyboard layout (language) and variant if any was set. I use the standard X11 XKB APIs to retrieve and parse the xkb_symbols set with setxkbmap.
2018-05-23 07:16:30 +01:00
components/keymap\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/load_avg\
Add network speed functions
2018-05-18 23:31:33 +01:00
components/netspeeds\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/num_files\
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
components/ram\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/run_command\
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
components/swap\
components/temperature\
components/uptime\
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
components/user\
components/volume\
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
components/wifi
Makefile: separate default flags from user flags
2018-04-30 15:11:45 +01:00
simplified Makefile
2017-01-09 08:29:58 +00:00
all: slstatus
what kind of weed is that?
2016-09-05 00:17:30 +01:00
Explicitly list component-objects in the Makefile There was a long tinkering process at farbfeld about this, but the sad truth is that it's the only way to make the Makefile truly portable. Listing it just as $(COM:=.o): config.mk $(REQ:=.h) omits the dependency on the c-file itself, which incurs that strictly speaking the object file is not depending on the source file, which is nonsense. You don't see strictly Posix compliant Makefiles around very often and most use nasty GNU-extensions everywhere. It is a good idea to go ahead as a fitting example and show how to write them portably.
2018-05-27 21:40:00 +01:00
components/battery.o: components/battery.c config.mk $(REQ:=.h)
components/cpu.o: components/cpu.c config.mk $(REQ:=.h)
components/datetime.o: components/datetime.c config.mk $(REQ:=.h)
components/disk.o: components/disk.c config.mk $(REQ:=.h)
components/entropy.o: components/entropy.c config.mk $(REQ:=.h)
components/hostname.o: components/hostname.c config.mk $(REQ:=.h)
components/ip.o: components/ip.c config.mk $(REQ:=.h)
components/kernel_release.o: components/kernel_release.c config.mk $(REQ:=.h)
components/keyboard_indicators.o: components/keyboard_indicators.c config.mk $(REQ:=.h)
components/keymap.o: components/keymap.c config.mk $(REQ:=.h)
components/load_avg.o: components/load_avg.c config.mk $(REQ:=.h)
components/netspeeds.o: components/netspeeds.c config.mk $(REQ:=.h)
components/num_files.o: components/num_files.c config.mk $(REQ:=.h)
components/ram.o: components/ram.c config.mk $(REQ:=.h)
components/run_command.o: components/run_command.c config.mk $(REQ:=.h)
components/swap.o: components/swap.c config.mk $(REQ:=.h)
components/temperature.o: components/temperature.c config.mk $(REQ:=.h)
components/uptime.o: components/uptime.c config.mk $(REQ:=.h)
components/user.o: components/user.c config.mk $(REQ:=.h)
components/volume.o: components/volume.c config.mk $(REQ:=.h)
components/wifi.o: components/wifi.c config.mk $(REQ:=.h)
Tweak build system a little bit Be consistent with brackets and add a comment for OpenBSD to make it clearer what the actual intent of the uncommented line is. In the Makefile, add a dependency of slstatus.o from config.mk.
2018-05-01 19:50:53 +01:00
slstatus.o: slstatus.c slstatus.h arg.h config.h config.mk $(REQ:=.h)
Explicitly list component-objects in the Makefile There was a long tinkering process at farbfeld about this, but the sad truth is that it's the only way to make the Makefile truly portable. Listing it just as $(COM:=.o): config.mk $(REQ:=.h) omits the dependency on the c-file itself, which incurs that strictly speaking the object file is not depending on the source file, which is nonsense. You don't see strictly Posix compliant Makefiles around very often and most use nasty GNU-extensions everywhere. It is a good idea to go ahead as a fitting example and show how to write them portably.
2018-05-27 21:40:00 +01:00
.c.o:
$(CC) -o $@ -c $(CPPFLAGS) $(CFLAGS) $<
Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
Fix missing config.h in Makefile
2017-09-17 21:31:26 +01:00
config.h:
cp config.def.h $@
Explicitly list component-objects in the Makefile There was a long tinkering process at farbfeld about this, but the sad truth is that it's the only way to make the Makefile truly portable. Listing it just as $(COM:=.o): config.mk $(REQ:=.h) omits the dependency on the c-file itself, which incurs that strictly speaking the object file is not depending on the source file, which is nonsense. You don't see strictly Posix compliant Makefiles around very often and most use nasty GNU-extensions everywhere. It is a good idea to go ahead as a fitting example and show how to write them portably.
2018-05-27 21:40:00 +01:00
slstatus: slstatus.o $(COM:=.o) $(REQ:=.o)
Revert component-split this reverts the commits from 92ab9ef52ebcb097add97d9f78e67ad1c1d6a6ec up to d42870d6ca7fb587b38f8cf6d6821ae33a53a696. After heavy consideration, the component split has more disadvantages than advantages, especially given there will be utility-functions sharing quite a lot of code that would then need to be duplicated, as it does not fit into the util.c due to its speciality. One big advantage of the component-wise build is readability, and without doubt, this was achieved here. This point will be addressed with a different approach that will be visible in the upcoming commits. One big disadvantage of the component build is the fact that it introduces state to the build process which is not necessary. Before its introduction, the only influencing factors where the system-defines __linux__ and __OpenBSD__. With the components, we are also relying on the output of uname(1). Additionally, if the os.mk is not present, make gives the output $ make Makefile:5: os.mk: No such file or directory make: *** No rule to make target 'os.mk'. Stop. This could easily be fixed by providing some sort of meta-rule for this file, however, it indicates the problem we have here, and this entire statefulness will heavily complicate packaging of this tool and makes the build process much more complex than it actually has to be.
2018-05-01 17:10:39 +01:00
$(CC) -o $@ $(LDFLAGS) $< $(COM:=.o) $(REQ:=.o) $(LDLIBS)
Makefile: Fixes #35
2017-01-09 07:24:26 +00:00
what kind of weed is that?
2016-09-05 00:17:30 +01:00
clean:
Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
rm -f slstatus slstatus.o $(COM:=.o) $(REQ:=.o)
what kind of weed is that?
2016-09-05 00:17:30 +01:00
Added Makefile target for distribution tarballs.
2017-08-13 22:05:22 +01:00
dist:
rm -rf "slstatus-$(VERSION)"
Move components into dedicated subdirectory This brings us a lot more tidiness.
2017-09-24 14:33:01 +01:00
mkdir -p "slstatus-$(VERSION)/components"
Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
cp -R LICENSE Makefile README config.mk config.def.h \
Get rid of HDR variable The HDR variable is used for general purpose headers, which are not given in this project. arg.h and config.h are only needed for slstatus.c, not every component $(COM:=.c). This also fixes a problem introduced in e04a3853643df1c98a451969d515d8850f138bcc, where config.h is pulled into the tarball.
2017-09-18 07:53:19 +01:00
arg.h slstatus.c $(COM:=.c) $(REQ:=.c) $(REQ:=.h) \
Rewrite Makefile to accomodate file split
2017-09-17 16:12:44 +01:00
slstatus.1 "slstatus-$(VERSION)"
Added Makefile target for distribution tarballs.
2017-08-13 22:05:22 +01:00
tar -cf - "slstatus-$(VERSION)" | gzip -c > "slstatus-$(VERSION).tar.gz"
rm -rf "slstatus-$(VERSION)"
what kind of weed is that?
2016-09-05 00:17:30 +01:00
install: all
Refactor build system
2017-08-10 20:32:10 +01:00
mkdir -p "$(DESTDIR)$(PREFIX)/bin"
cp -f slstatus "$(DESTDIR)$(PREFIX)/bin"
chmod 755 "$(DESTDIR)$(PREFIX)/bin/slstatus"
mkdir -p "$(DESTDIR)$(MANPREFIX)/man1"
cp -f slstatus.1 "$(DESTDIR)$(MANPREFIX)/man1"
chmod 644 "$(DESTDIR)$(MANPREFIX)/man1/slstatus.1"
what kind of weed is that?
2016-09-05 00:17:30 +01:00
uninstall:
Refactor build system
2017-08-10 20:32:10 +01:00
rm -f "$(DESTDIR)$(PREFIX)/bin/slstatus"
rm -f "$(DESTDIR)$(MANPREFIX)/man1/slstatus.1"