[cmake-developers] CPack BAR package generator

[Stephen Kelly]

Eric Noulard wrote:

> 2013/9/20 Stephen Kelly
> <steveire at gmail.com>:
>> Stephen Kelly <steveire at ...> writes:
>>>  https://gitorious.org/~steveire/cmake/steveires-cmake
>>>
>>> It is the start of a CPack generator for BlackBerry BAR packages,
>>> required for deployment to those devices. I haven't worked much with
>>> CPack before, so I'd appreciate some feedback even at this early point.
>>>
>>
>> Eric, and response to this?
> 
> I'm looking at it right now.

Thanks!

> 
> 1) You lack at least a CPackBAR.cmake in which you should put
>    the documentation for each CPACK_BAR_xx specific variable usage.
>    Have a look at CPackWIX.cmake or CPackRPM.cmake etc....
> 
>    You can check if it's working with:
>    cpack --help-variable CPACK_BAR_xx

Ok.

> 
> 2) You shouldn't do
> 
>    add_custom_target(bbpackage
>        COMMAND ${CMAKE_CPACK_COMMAND} -G BAR
>        )
> 
> but
> 
>     set(CPACK_GENERATOR "BAR")
> 
> then "make package" or "cpack" with no args in the build tree should
> biuld a BAR package.
> see cpack --help-variable CPACK_GENERATOR

What if I want a bbdeploy make target which first builds the package and 
then deploys it (as in the example in my commit message linked above)? 

What if I additionally want to have an android_deploy which builds an 
android package and then deploys it? 

My solution seems to be more scalable than hardcoding CPACK_GENERATOR. 
However, it is also irrelevant. It's an example of what user-code could look 
like, not something that would reach cmake/cpack itself.

> 
>    3) Depending on how much flexibility you want you may chose to do
> some of the work
>        inside a CMake script like CPackRPM.cmake does or do all you want
>        to do inside the C++ code (cmCPackBARGenerator::PackageFiles) like
> NSIS or DEB does.
>        Offering some trap in your CPackBAR.cmake may ease

I'll have a look. Would the user then provide their own CPackBar.cmake to 
override my provided one? At least if we do it all in C++ at the start, it 
can be added later, but if we add such hooks now, we can't remove them. I'd 
prefer to add stuff like that only when needed.

> 
>    4) You should obviously have some tests for it.
>    (<CMakeSource>/Tests/CPack*)
>          4.1) ensure that CPackTestAllGenerators/ works
>                 and may be CPackComponents/
> CPackComponentsForAll/  as well.
> 
>          4.2) develop BAR specific test like for CPackWiXGenerator/

Yes.

> I do not have the time to do a test build yet, but I'll try.

Do you mean by downloading and using the bb10 ndk? Yes, that would be good 
if you could test that additionally.

Do you have any thoughts relating to the possibility of naming it BAR_NATIVE 
instead, so that the namespace can be extended with BAR_PYTHON in the 
future?

Do you have any thoughts on the CPACK_PACKAGE_CONTACT problem? Namely that 
the debian generator and the BAR generator have differing expectations on 
what such a thing would contain. Should we have separate 
CPACK_PACKAGE_CONTACT_NAME and CPACK_PACKAGE_CONTACT_EMAIL variables?

Thanks,

Steve.