Date: Tue, 18 Jan 2005 01:18:24 +0100 From: "Simon L. Nielsen" <simon@nitro.dk> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-ports@FreeBSD.org Subject: Re: Makeing fetchindex really mirror INDEX Message-ID: <20050118001824.GM41278@zaphod.nitro.dk> In-Reply-To: <20050109185948.4470a02d@Magellan.Leidinger.net> References: <20050109143903.GC1187@zaphod.nitro.dk> <20050109174945.7f0353e4@Magellan.Leidinger.net> <20050109170219.GF1187@zaphod.nitro.dk> <20050109185948.4470a02d@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Z9t8O/5YJLB6LEUl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[Sorry for the delay]
On 2005.01.09 18:59:48 +0100, Alexander Leidinger wrote:
> On Sun, 9 Jan 2005 18:02:20 +0100
> "Simon L. Nielsen" <simon@FreeBSD.org> wrote:
>=20
> > Mainly because we already have a ${INDEXFILE} target, and the two
> > would conflict, so I thought it would be simpler to keep the simple
> > target.
> >=20
> > make index in your patch only works because you don't define
> > ${INDEXFILE} as ${.CURDIR}/${INDEXFILE}, which it should be since
>=20
> Correct.
>=20
> > there might be a object directory. At least as I read it, I could be
> > wrong.
>=20
> At the time I wrote the first implementation of "fetchindex" it was
> supposed to be run at the time as "update". So the PORTSDIR has to be
> writable (except I've overlooked something). If this hasn't changed,
> there's no need for .CURDIR.
You could (in theory) have a object directory and still use a
writeable "source" directory (ie. writeable /usr/ports). This
scenario is rather common in src/ and would be (if it wasn't broken
:-) ) in doc/. I now got around to looking a bit more on
ports/Makefile and found out that it has no "make obj", so it's
probably very unlikely that anybody actually has a object directory
for ports, though the normal index target is made to handle the case
anyway.
> > the right way, I just don't see a really clean way to implement it the
> > right way (well, ${INDEXFILE}.bz2) could probably be used but it would
> > still only be half way there).
>=20
> Without changing the index target, I don't see a cleaner way.
The only somewhat cleaner way I can think of is:
fetchindex: ${.CURDIR}/${INDEXFILE}
=2Eifmake fetchindex
${.CURDIR}/${INDEXFILE}: ${INDEXFILE}.bz2
=2Eelse
${.CURDIR}/${INDEXFILE}:
# Current "real" index target
=2Eendif
But I'm not really sure if that has other implications I can't see.
Thinking more about it, I don't really care much how "correct" the
solution is, just that it works :-). So it's fine by me just to use
your version.
> > > BTW.: if I do it the right way (".PHONY: ${INDEXFILE}.bz2" instead of
> > > adding " .PHONY" to "${INDEXFILE}.bz2:"), it doesn't work here
> > > (6-current) as expected.
> >=20
> > I would guess the problem is also related to .CURDIR, but I'm not
> > sure.
>=20
> I don't see where .CURDIR is supposed to change the behavior here. We're
> talking about targets, and I've specified them the same at both places.
I guess your right, that should not really matter for this.
--=20
Simon L. Nielsen
--Z9t8O/5YJLB6LEUl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFB7FXQh9pcDSc1mlERAgomAJ44NtVPvPUYCAtXZgwTwx4vtSmx4ACeNMxd
PwNkoXIJHI8d4Vk+AerxSPA=
=wPys
-----END PGP SIGNATURE-----
--Z9t8O/5YJLB6LEUl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050118001824.GM41278>