2011/9/7 Stuart Henderson <[email protected]>:
> On 2011-09-06, Amit Kulkarni <[email protected]> wrote:
>> On Tue, Sep 6, 2011 at 1:24 PM, Vadim Zhukov <[email protected]> wrote:
>>> Just added a "debug" flavor, and for sanity re-run "make
>>> update-plist". It was not a big surprise something was changed; the
>>> surprise was that ${FLAVORS} got there:
>>>
>>> --- pkg/PLIST.orig ? ? ?Tue Sep ?6 01:49:39 2011
>>> +++ pkg/PLIST ? Tue Sep ?6 22:20:05 2011
>>> @@ -18,7 +18,7 @@ lib/cmake/
>>> ?lib/cmake/Akonadi/
>>> ?lib/cmake/Akonadi/AkonadiConfig.cmake
>>> ?lib/cmake/Akonadi/AkonadiConfigVersion.cmake
>>> -lib/cmake/Akonadi/AkonadiTargetsWithPrefix-release.cmake
>>> +lib/cmake/Akonadi/AkonadiTargetsWithPrefix${FLAVORS}.cmake
>>> ?lib/cmake/Akonadi/AkonadiTargetsWithPrefix.cmake
>>> ?@lib
>>> lib/libakonadiprotocolinternals.so.${LIBakonadiprotocolinternals_VERSION}
>>> ?lib/pkgconfig/akonadi.pc
>>>
>>> Not a big deal, of course, but is this a known issue?
>>>
>>> --
>>> ? WBR,
>>> ? Vadim Zhukov
>>>
>>>
>>
>> And a question, different FLAVORS are not reflected in PLIST, should
>> we use multi-packages instead? how to make the decision to use FLAVOR
>> or MULTI_PACKAGES?
>
> MULTI_PACKAGES is where you can split a package up e.g. if it has plugin
> modules or language bindings which don't all need to be present. It's
> useful for reducing the set of required dependencies. Think e.g. something
> with mysql/pgsql/sqlite support in 3 separate plugins.
>
> FLAVOR is where a file is built differently depending on build options,
> e.g. to carry on the example, if rather than modules, db support is compiled
> right into the main binary.
>
> For PLISTs you can use PFRAG with %%flavor%% markers in PLIST.
> Look for existing multi-flavour ports for examples.
>
> In this case I guess this filename probably does not change so you
> override what update-plist does and leave the filename as
> AkonadiTargetsWithPrefix-release.cmake
Unfortunately, it changes, because CMake is given different profile:
(in Makefile)
.if ${FLAVOR:L:Mdebug}
CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
CMAKE_TARGET_PREFIX = -debug
.else
CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Release
CMAKE_TARGET_PREFIX = -release
.endif
SUBST_VARS += CMAKE_TARGET_PREFIX
(in PLIST)
share/apps/cmake/modules/KDELibs4LibraryTargets${CMAKE_TARGET_PREFIX}.cmake
My first decision was to just comment those PLIST entries out, but
looks like they're being used by other packages.
Anyway, main problem is not the needance of this dance (probably it
should be done better, packaging files for both configurations). But
that "make update-plist" does compacting incorrectly, removing
preceding dash.
--
WBR,
Vadim Zhukov
