gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] parallel compilation


From: Simon Sobisch
Subject: Re: [open-cobol-list] parallel compilation
Date: Tue, 20 Sep 2016 22:19:31 +0200

> If I may, I would add that [automatic/parallel compilation] is what make was 
> invented for!
> 
> My GNU Makefile often starts with some variation of
> 
> COB.SRC = $(wildcard $(COB.DIR)/*.cbl)
> COB.BAS = $(basename $(COB.SRC))
> cobol: $(COB.BAS)
> 
> Then "make -j8" runs the build in parallel, only remaking what's out of
> date.

Thank you for the sample makefile part, this is similar to what I've meant.

> > This is defined in common.c around line 3281 and uses:
> >
> > cob_gettmpdir(), SLASH_CHAR, cob_sys_getpid(),
> > cob_temp_iteration, ext
> > You can override the temporary direcory which you did (first part),
> > but this shouldn't be necessary as the second part is the process-id
> > which shouldn't be reused within a time frame needed for compilation.
> >
> > This is quite strange and should be investigated further!
> 
> +1. I looked at the same code briefly, and it appears to use the pid
> as part of the temporary filename. It would be better, though, to use
> tempnam(3).

No. I've checked this the last hour and while tempnam(3) would be usable on 
many systems (we'd add a configure check for it in any case) it is marked as 
obsolete and is seen to be more insecure than what we have. If we use it we 
would therefore use the current one as prefix and I'm not sure the additional 
little overhead added is worth as the original problem simply should not 
happen. The only possible issue I see is a broken cob_temp_iteration, we should 
at least check this.
If we change something here it is more likely to use mkstemp(3) which would 
need more code changes and the fallback to the current one for systems where 
mkstemp is not available.

Simon


reply via email to

[Prev in Thread] Current Thread [Next in Thread]