search

troglobit / finit

Fast init for Linux. Cookies included
https://troglobit.com/projects/finit/
MIT License
633 stars 63 forks source link

Improve build scripting #141

Closed concatime closed 3 years ago

concatime commented 3 years ago

I also fixed the non-POSIX OR operator test x -o y.

troglobit commented 3 years ago

Quite a few changes, without any real motivation than "for consistency" and "improvements". Could you perhaps tell me a bit more why you want to do this? What system/shell has been giving problems?

concatime commented 3 years ago

Yeah, sorry, I was in a hurry.

1.

Even tho the second form, [, is POSIX compliant, GNU autotools and gnu-config use solely on the first form, test, and not without reasons.

it's common practice in the basic utility scripts to use test

Source.

I’ve detailed here why test is supperior. I already made the changes on other repos, like CMake.

2.

Finit is solely built for Linux systems, where GNU make is the canonical standard

Even tho in practice, GNU Make is the defacto make command on most machines, there is no specification that that guarantees so. For instance, in my machine, I have make symlinked to bmake (smake is another alternative). I am able to build libite and libuev with bmake too. And looking at the specification of POSIX make, thre is no -C argument. So cd ... && make is the portable way. Your argument is arguably the same for GNU Bash.

Finit is solely built for Linux systems, where GNU bash is the canonical standard

But that’s not a reason to not write your scripts in a POSIX compliant manner. (is /bin/sh bash? is /usr/bin/make gnu make?)

That being said, I just wanted to improve your code base a little bit :)

EDIT: Sorry, GitHub’s markdown in comments is broken. That’ how it should look.

troglobit commented 3 years ago

OK, so basic drive-by pull request. Thank you, but no thanks.

Improve is a very subjective thing, and since you're likely not going to be here in ten years, I prefer to keep my style on the scripts, since I'm the one who have to maintain them.

And, like I tried to say above. Portability to other POSIX systems is not a primary concern. Getting it to build on other Linux systems is, uClinux, musl, and GLIBC-based Linux systems. Sorry if my bad English was hard to understand, it's not my first language. The scrips are already POSIX compliant, and Finit will never target anything else than Linux systems. (Because it has heaps of Linux-specific code in it, and really only makes embedded ppl happy.) If the day comes and we need to support other make implementations than the de facto GNU make, I hope I will be long dead by then.

concatime commented 3 years ago

The scrips are already POSIX compliant

That’s not the case. if [ "x$yorn" = "xy" -o "x$yorn" = "xY" ]; then is not POSIX. And it’s present 6 times. I fixed them in this PR.

Portability to other POSIX systems is not a primary concern.

What do you mean by "other"? My environment is Linux. It just happens that I don’t use GNU make as my make. Nor coreutils as my tools (busybox and sbase). But it’s still Linux. Still POSIX. The irony is that some people say that systemd is Linux. But you offered an alternative. And now you’re saying gnu make is Linux. I am fine with GNU Make, but just make it explicit in the README. This way, I can adapt my build system.

troglobit commented 3 years ago

OK, sure. That's not POSIX, but last I tested it worked with Busybox ash, and Debian's dash. Those two make out just about 100% of the POSIX style shells for Linux today.

You have not stated anywhere what actual problem or bug your pull request addresses. I've successfully built and installed Finit on a heap of embedded systems running various incantations of C libraries, with or without GNU Coreutils or Busybox. Granted, most of those builds have been cross-compiled, but far from all. If you want to port Finit to another Linux based system, or variant of make, that's fine. But please state that clearly when presenting the pull request. And possibly make several pull requests for separate issues. You're the one who wants a change in my project, so tell me your use-case. If there are more people out there then there may be some interest from me, but if it's a fringe target with very few users, I see no point in supporting it too. I'm only one person in this project and I have to maintain focus, I'm sure you understand.

I've been around UNIX and Linux for 25+ years, and maintained this project for 10+ of those years, and have never even heard of bmake before. Heard of many others, but not that one. Googling a bit it seems to be the same make that I know as pmake in NetBSD ... and that is one hairy beast I don't want to see again.

Also, just because I offer an alternative to systemd doesn't mean I'm prepared to bend over backwards to support any weird system based on Linux out there. There are a lot ...

concatime commented 3 years ago

See, that’s exactly why [ is bad. It is not a shell operator! It has nothing to do with busybox ash nor dash. I explained it here. [ is a command from GNU coreutils '/usr/bin/['. If you use the test command from sbase instead (as I do), you will encounter too many arguments. That being said, some shells, to improve speed, come with builtins ([, test, echo, etc.).