Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Aug 2005 20:36:52 +0200
From:      Emanuel Strobl <Emanuel.strobl@gmx.net>
To:        David Kirchner <dpk@dpk.net>, freebsd-questions@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: make ".if exists" problem/question
Message-ID:  <200508252037.04779@harrymail>
In-Reply-To: <35c231bf05082511101884faf@mail.gmail.com>
References:  <200508251951.37319@harrymail> <35c231bf05082511101884faf@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1717290.fUS4t3WGq6
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 25. August 2005 20:10 CEST schrieb David Kirchner:
> On 8/25/05, Emanuel Strobl <Emanuel.strobl@gmx.net> wrote:
> > Dear make gurus (bsd make, not gmake),
> >
> > it seems that make checks .if directives only at statrup. How can I
> > trigger a "reread"?
> > I have the problem that in one target I create a filetree, another
> > target checks if it exists, if not it creates itself again. Now it
> > works perfectly when I call the two targets both externally
> > (installcfworld installcfconfig) but when the internal higher
> > "install" gets to the installcfconfig target it fails!
> > I'm really desperate, I need to check this. Is this a nasty bug?
>
> This Makefile shows the problem:
>
> all:
> .if ! exists(./foobar)
>         @echo foobar does not exist
> .endif
>         touch foobar
> .if ! exists(./foobar)
>         @echo foobar does not exist
> .endif
>
> If you run make in this directory, and foobar does not already exist
> beforehand:
>
> $ make
> foobar does not exist
> touch foobar
> foobar does not exist
>
> Looking at the make source, it appears that it maintains a cache for
> file lookups, and I don't see a way to have it flush the hash via some
> makefile command. I dunno if it is a bug but the man page does not
> mention a cache.
>
> I wonder if you'll have to start a separate make process for each
> stage of that target's handling.

Thanks for your suggestion, you described exactly what I mean. So if=20
there's no way to flush the cache, it's IMHO a wrong behaviour and should=20
be considered as bug.
I'm not too experienced in make, so I don't know if I want to call sub=20
makes...
Do you have an idea whom to contact regarding the "bug"?

Thanks,

=2DHarry

--nextPart1717290.fUS4t3WGq6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQBDDg/QBylq0S4AzzwRAoqqAJ9N/2+ZJ6kW3Kn2XaeZwS8Vt7pXuACfeS4l
qYSFNWm08LNDiApwDeTz5nQ=
=d1wd
-----END PGP SIGNATURE-----

--nextPart1717290.fUS4t3WGq6--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508252037.04779>