cygport: variable package names

Yaakov (Cygwin/X)
Sun May 6 21:35:00 GMT 2012

On 2012-05-04 17:27, Corinna Vinschen wrote:
> On May  4 15:34, Yaakov (Cygwin/X) wrote:
>> On 2012-05-04 03:37, Corinna Vinschen wrote:
>>> Yaakov, Ping?
>>> my workaround has a problem, see below.
>> Yes, because the P* variables aren't set that early.

Correction: P* are set, its S/B/C/D that aren't set yet.

> I understand your concern, but on the other hand the current method
> also has a downside.  The creator of the cygport file has to specify
> the runtime name including the ABI version as a fixed string.  First
> of all, there's a chance that the package creator just doesn't know
> beforehand which ABI version will be generated by the package.  And
> second, since the ABI version is just hardcoded in the cygport file,
> there's also a chance that the package maintainer misses the ABI version
> bump and creates a package "libfoo1", while the DLL in the package is
> called cygfoo-2.dll.

Only if you do something like libfoo1_CONTENTS="usr/bin/*.dll", which is 
a bad idea for this very reason.

> I think that, either way, you have to rely on the diligence of the
> maintainer.  Allowing to automate the package naming and dependency
> generation in the package stage, rather than in the install stage,
> would at least ease the job, IMHO.

Unfortunately S can't be defined before source()ing the .cygport, 
because SRC_DIR may be defined by the .cygport or a cygclass, which 
affects S.  Hence this becomes a bit more complicated; as I said, I'll 
have to look into possible solutions.


More information about the Cygwin-apps mailing list