Re: multi-threaded compiling
On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > I've attached the problem. It consists of two parts: > > 1) multi-threaded bash script and / or multi-threaded Makefile > > Running bash script functions as expected, but executing the same > line of code with make and / or the command line, does not function. > Perhaps someone could explain to me why? > > 2) passing a string argument from a bash script and / or Makefile to > the gcc -D option > > Running the makefile functions as expected, but I have not been able > to get similar code to work from a bash script. Can someone please > explain to me what I'm doing wrong? I don't understand the problem. In the third paragraph above you say the bash script works as expected and the makefile doesn't work, but in the last paragraph you say that the makefile works as expected but you can't get it to work in bash. Please provide actual command invocations (cut and pasted) showing the output you received and explaining exactly what is wrong with it. But before you do that, be aware that make does NOT invoke /bin/bash as its shell. It invokes /bin/sh. On some systems /bin/sh is actually an alias for bash. On other systems it isn't. If you want your makefile to always use bash as its shell, you should add an explicit: SHELL := /bin/bash to your makefile to force it. Maybe that will solve your problem. If not we'll need details such as I mention above.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote: > The actual command invocations (a Makefile, a make.sh script) can be > found in the attachment, as indicated on the first line of the mail. > In the attachment there are two directories, one and two, belonging > to 1) and 2) respectively. That's not what I asked: I asked YOU to run the commands on YOUR system and cut and paste the results of the run into your email message, with an explicit explanation of exactly what is wrong with the results and what you wanted to see instead. What errors did you get? Or what was unexpected about the behavior? I'm not interested in running random scripts on my system that were downloaded from an email, or examining their behavior to make sure they're OK, or setting up a container to run them in, or guessing what you wanted to happen, etc. Or maybe someone else will want to do that work instead. But before putting in more effort on the "misbehaving" makefile, read this part of my response carefully: > But before you do that, be aware that make does NOT invoke /bin/bash > as its shell. It invokes /bin/sh. On some systems /bin/sh is > actually an alias for bash. On other systems it isn't. > > If you want your makefile to always use bash as its shell, you should > add an explicit: > > SHELL := /bin/bash > > to your makefile to force it. Maybe that will solve your problem. > If not we'll need details such as I mention above. and verify in your response you added the suggested line to your makefile and it didn't help (in the situation where the makefile was behaving in an unexpected way).
Re: multi-threaded compiling
On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote: > /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop > variable This is because of the issue I mentioned in my initial reply. This invocation is using /bin/sh which is a POSIX shell but is not bash; probably it's dash or similar (you are running on Debian or one of the GNU/Linux distros that build on it). If you set "SHELL := /bin/bash" (or whatever the path is for bash on your system) in the makefile you won't see this, I expect.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote: > You won't be able to take advantage of "wait -n"'s ability to react > to the first job that finishes. You'll end up reaping each job in > the order they started, not the order they finished. It feels to me like you're trying to reproduce make's already-available parallel build support, in a kind of kludgy way with bash. Maybe this is an XY problem and you should step back and describe WHY you're trying to create this behavior using bash instead of just using make's support for parallel jobs. What about make's parallel jobs doesn't meet your requirements (or put another way, what actually are your requirements)?
Re: multi-threaded compiling
On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > I'd still like to hear why you aren't simply using "make -j". > > That's because I don't want to define static compile and link targets > for every new project I start. The Makefile in question contains only > a few lines of code and some environment variables, but works on > every new project as long as you follow certain guidelines regarding > the directory structure. It scans, compiles and links on the fly. I don't find this argument compelling. It's relatively straightforward to create a makefile environment that "works on every new project as long as you follow certain guidelines regarding the directory structure" while still using parallel builds, that will "scan, compile, and link" on the fly, using things like the wildcard function, pattern rules, etc. You are merely trading a bit of extra complexity in your makefile for a whole lot of complexity and tricky hacking in bash, as can be seen by following this thread. But if you prefer to re-invent make's parallel build capabilities in bash, certainly that's your prerogative.
Re: Bash security issue
On Fri, 2014-09-26 at 10:51 -0400, Steve Simmons wrote: > 2) build a 'real' /bin/sh without those compiled in. This begs the > definition of 'real', but IMHO if it's not in POSIX, it shouldn't be > in 'real' /bin/sh Ubuntu and it's derivatives have been doing this since 2006. /bin/sh on these systems is dash: https://wiki.ubuntu.com/DashAsBinSh They get a lot flak for it amongst people who care more about having things work than having things portable, but they've stuck to their guns so far. Probably this current situation leaves them feeling justified and even more resolute. As someone who develops a lot of embedded software and is constantly burned by people throwing badly-written bash-specific scripts into their packages, I have really appreciated them taking this stand. It would be great if Red Hat would also join in, but I cannot imagine that happening, ever: way too much would break for too little gain.
