[cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

> Thanks for the explanations. Which raises new questions:
>
> How would I create empty lists then (to which I can subsequently append)? Or
> check that a variable is defined? Or tell the calling function that the
> output variable is set to an empty string?
> Those questions should sound very naive, but this is less than obvious to
> me.

Lists in CMake are strings separated by semicolons
"first_element;second_element" so empty list is an empty string "".

Also you don't even need to create a list variable before appending to
it - first list(APPEND ...) call will create the variable for you.

Testing if(DEFINED) tests if variable actually exists - if it's an
empty string that still means that it exists.

set(var) is the same as unset(var) -> in both cases if(DEFINED var)
returns false. So writing set(var) doesn't create an empty string/list
instead it's only a more cryptic way of saying unset(var).

For eg.
set(a "") -> defined to empty string
set(b ${a}) -> in this case b is undefined
set(c "${a}") -> in this case c is an empty string

So if you don't use quotes with set you can get odd errors so it's
better to be consistent.

>
> For instance
>
> string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
> set(_component_shlibdeps_var
> CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)
>
> if(DEFINED ${_component_shlibdeps_var})
>   ...
> The variable _component_shlibdeps_var clearly is defined and contains a
> string that names/points a variable. In the if statement, I am checking if
> the variable pointed by _component_shlibdeps_var is defined by the user. It
> is not clear to me why I would put quotes in this case, there is no risk for
> _component_shlibdeps_var being an empty variable.
>
> Would it be better with/equivalent to:
> if("${_component_shlibdeps_var}")
>
> ?

No in this case you're right but I prefer using quotes in set()
because of empty string errors - I forget to write them from time to
time but I try to be consistent.

>
> Another example is
>   if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT
> CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL "")
>
> The intention is to check if CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS is defined
> and is not an empty string. Here I added the 'NOT
> CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL ""' to an existing statement. Is
> it equivalent to
>
> if(NOT "${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}" STREQUAL "")
>
> ?

Yes it's equivalent.

> Again
>
> set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
> is not the same to me as
> unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
>
> and actually comes from the line
> set(CPackComponentsForAll_BUILD_OPTIONS)

To cmake they are the same and I had to test that first... I thought
that set(var) meant set(var "") - this was my mistake.

>>
>> That is why I mentioned that you aren't using any quotes most of the
>> time while using variables.
>
>
> When I look at the changes you made,
>
>     set(options "")
>     set(oneValueArgs "FILENAME")
>
> and from here
>
> http://www.cmake.org/cmake/help/v3.2/module/CMakeParseArguments.html?highlight=cmake_parse_argument
>
> I do not see the value of putting the quotes in fact, especially around
> FILENAME, since there are already quotes around ${option}, etc in the call
> to cmake_parse_arguments.

set(options "") was my mistake... Now I know that it should have been
unset(options) or even better delete the variable and its use all
together.
For the FILENAME it's just consistency - using quotes where the text
is a string and doesn't represent a variable name that is used by
list, if and other functions.

Also the reason for mentioning quotes in if statements was that I did
not know that
set(var "a b c")
if(${var} STREQUAL "a b c")
produces correct result. I expected that it would expand to a list as
it would for set(var a b c).

So in the end other than me having allot more difficulties reviewing
the patch most of the nonquoted variables/values are not important.
The thing is that during a review when I see a non quoted string I
have to go all the way to where it was set and be certain that it
can't be assigned to an empty value, with most of the quotes in place
the review gets allot simpler for me.

> Can it be in a subsequent patch or I should rework those? (reworking the
> patches is more work for me.)

You can create new patches and I'll do the merge.

Thanks,
Domen