Hi Paul!
Thanks for the detailed answer.
> Le 10 nov. 2017 à 17:50, Paul Smith <psm...@gnu.org> a écrit :
>
> On Fri, 2017-11-10 at 17:36 +0100, Akim Demaille wrote:
>> in other words, cd respects my symlinks, but make -C resolves them.
>
> These statements don't
Hi friends!
I have been bitten (or beaten, I guess both convey the same idea :)
but the following difference between `cd dir && make` vs.
`make -C dir`:
> $ cat foo.dir/Makefile
> all:
> cd bar && make
> make -C bar
> $ cat bar.dir/Makefile
> all:
> pwd
> $ ls -l foo.dir
Le 3 mai 2011 à 18:04, Paul Smith a écrit :
I'm confused in understanding why it's rightly confused :/ But maybe
my confusion is, as Edward pointed out, because I am misled by the
term circular dependency, as really, I can't see any here.
Maybe circular is not the best term; as Edward
Le 3 mai 2011 à 15:03, Edward Welbourne a écrit :
Hi Edward,
Thanks a lot for your detailed explanation.
Because there are two routes through the dependency graph from %.eps
to %.dat, one going directly, the other going via %.pdf, make has an
ambiguity it can't sensibly resolve (if any
Hi all,
First of all, thanks a lot for the good work on GNU Make!
I have a piece of Makefile that started behaving differently in the migration
from 3.81 to 3.82, and I'm tempted to call it a bug.
Using the attached Makefile (I spent quite a while to strip it down from an
Automake generated
| Hi,
|
| make-3.79.1, built on a recent glibc snapshot, links with the shared
| library libutil, but doesn't any symbol from this library! Of course
| this costs startup time.
|
| The reason is the AC_FUNC_GETLOADAVG macro. It checks for getloadavg
| in -lutil. Now glibc-2.2 has getloadavg in
