Re: building (with) execline

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Tue, 13 Jan 2015 00:58:35 +0100

On 01/13/15 00:51, Laurent Bercot wrote:
> On 12/01/2015 22:27, Olivier Brunel wrote:
>
>> I may be wrong, but the way I read the info page about this (4.5.6
>> Directory Search for Link Libraries) I took it that this special
>> handling of processing -lFOO and looking in directories for e.g.
>> libFOO.so then libFOO.a (by default) was only done as such, i.e. to
>> search for the prerequisite (and see if a rebuild is needed if more
>> recent), but when that search fails to find something, then it fails.
>>
>> Because make doesn't know which would be found/used, it has no recipe to
>> build it (e.g. how would it know whether to build libFOO.so or
>> libFOO.a?), as indicated by the error (no rule to make -lexecline)
>
> Then how do you explain that it works in the non-parallel case ? The
> sequence of actions you described applies too.

Simply because make process in order, and first there's making the
library file, *then* making the binaries (so linking against the lib),
as per your Makefile. So when it comes to that, the libFOO.a already
exists and there's no issue.

With parallel jobs, the process making the library might still be
running while it'll start the job building the first binary, because it
has no knowledge that it should wait.


>> If you don't have one by the time of next release, may I suggest simply
>> adding a target .NOTPARALLEL so that the -j flag is basically ignored.
>> Doesn't really solve anything, but at least it will always build.
>
> Good idea, I'll do that.
>
>
>> I see, good to know. So I'll do some reading re: buffered IO, but just
>> to make sure: the buffer_0, buffer_0f1, buffer_1, etc are ways to use
>> stdin, stdout and stderr directly with "pre-allocated" buffers, right?
>
> Yes, exactly.
> You shouldn't use buffer_0f1 unless you're writing a blocking filter.
> buffer_0f1 is just like buffer_0 except that it flushes buffer_1 right
> before attempting to read on stdin - which means that everytime your
> program risks blocking, it makes sure stdout is flushed first. It's
> optimal buffering behaviour for a filter (way better than the standard
> line buffering / full buffering distinction), but it's hackish, so
> make sure you do not use it outside of this very specific case.
>
>
>> And, so long as I don't mix e.g. buffer_1 with buffer_1small, I can use
>> them in my code safely?
>
> Yes. Just don't mix small with non-small and you'll be fine. :)
>
Received on Mon Jan 12 2015 - 23:58:35 UTC