Re: [boost] Fwd: Installing CMake configuration files

Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Peter Dimov (pdimov_at_[hidden])
Date: 2018-10-20 00:29:39

Steven Watanabe wrote:

> Getting the library name this way isn't too bad.

It may even be called trivial, as I already receive it in $(sources) in 
generate-cmake-variant and can just take $(src).name. However, I have to 
pick the right source for that, as I want the import library on Windows (but 
only on Windows) and for a DLL I get three sources from MSVC (.dll, .lib, 
.pdb) two for Cygwin g++ (.dll.a, .dll), and their order doesn't even match.

> Just pass it through all the generate/action logic
> and then in `generate-cmake-variant-` say:
> local fname = $(sources:BS) ;

Yeah, I haven't been able to figure this part out. How do I pass the 
$(sources) from generate-cmake-variant to generate-cmake-variant-'s sources? 
I was going to use a free feature for the fname.

> The logic for choosing static/shared/import lib is really annoying 
> actually.  The test you have ([ os.name ] = NT) is definitely wrong, as it 
> should be based on the target-os.  Also cygwin needs import libs (IIRC, 
> cygwin can link directly to a dll, but there are a few corner cases that 
> don't work right.).

[ os.name = NT ] may be wrong but it does handle Cygwin the right way. :-)

> # Process virtual targets containing a LIB
> # target.  IMPORT_LIBs take priority if both a
> # SHARED_LIB and an IMPORT_LIB are present.
> # Note: There might be other random files like *.pdb,
> # which are ignored.  Call this in generate-cmake-variant
> # to filter the sources to pass to the action.
> local rule .choose-lib-target ( sources * )
> {
>   local result ;
>   for local t in $(sources)
>   {
>     if [ type.is-derived [ $(t).type ] IMPORT_LIB ]
>     {
>       return $(t) ;
>     }
>     else if [ type.is-derived [ $(t).type ] LIB ]
>     {
>       result = $(t) ;
>     }
>   }
>   return $(result) ;
> }

Ah, you've answered my question from above. Thanks. :-)

> Automating the dependencies is harder,

That's what I thought. :-)