Re: RFD/CFT: www/angie: use upstream versions for all modules; using intermediate variables for DISTVERSION/PORTREVISION?

Sebastian Oswald <[email protected]>
Newsgroups gmane.os.freebsd.devel.ports
Message-ID <[email protected]>
Hello Gleb,

> I don't get it, why not use ?= when setting PORTREVISION in the master port?
> This is a common technique to allow slaves to override master port's variables.
> 

Thanks for that suggestion. I hope I haven't misunderstood you, but the
problem is not that I want to ovverride PORTREVISION in the master port
- the problem is that if PORTREVISION is set in a slave port, it
propagates to the version of the master port (angie) for the build
process of that slave port.
E.g. setting PORTREVISION=1 for a www/angie-module-* port results in a
dependency to 'angie-<version>_1' which of course does not exist.
I'd have to set the PORTREVISION in the master port (too), which
triggers an unnecessary rebuild of *all* modules and also bumps their
portrevision even if there were zero changes.

But more importantly, regarding using the upstream versions for the
slave ports, I can't override the masters DISTVERSION from the slave
port, because in the master Makefile this is of course used for the
angie version (and hence parts of the module build process as well).
If I override the DISTVERSION, the build fails as there is of course no
angie version that corresponds to the module version.
If the master Makefile dictates the DISTVERSION, all modules again get
the angie version appended (i.e. the status quo).

For the build of a module which results in it carrying its upstream
version number, I need to have both versions accessible - the version
of the master port (angie) and the upstream version of the module.

There's a good chance I'm overthinking this, and/or I may lack knowledge
of some important mechanism available in Makefiles to handle those
different version numbers for slave and master port. That's why I asked
here on the mailing list.

Thanks,
Sebastian

-- 
Sebastian Oswald
GnuPG-Key-ID: 0x313F3181
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEErQouifc5ybqTEVgvLx1vPG8zTyoFAmjyO0oACgkQLx1vPG8z
Tyo+Swf+L4LCOvufjVIr23mcHWBRPudZurWKKit8zJWiCkwx8qsp83+TiEjLQ0e1
Iey9Z6PQ91DvKYueW72IVFvjP9UenPmzi9UIAxN2ncFlB60CoQi3TGHZCuYYc2pk
EWfxoqR5DEaRooVpWhdwm8xIW5B57vtjGkrYwTn7+aEJtWAHMeoiN09vYLKunx5g
uBs7iM5mnpGlEzMsrFtO5eH6B5HVlhZ1hrRIYKt9JiBfN1z6MMb0vmkUU/Dhvy3Y
12ETbbNMP+0bYXBayog5VSf1A486Z5Uxp2FiQ0KFd8Ob/9E0v66wXYzpYlb6CrKM
M65SAJwD2wHzYx8GvNNcA9ArnNdLhg==
=exNK
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.