That could be a reason why I thought we need two symbols for a
feature. For example, USE_GPFS_FSAL could be used at cmake command
line and GPFS_FSAL could be used in the option().
Can't we use this option() inside conditionals?
regards, malahal.
On Thu, Mar 22, 2018 at 8:43 PM, Daniel Gryniewicz <d...@redhat.com
<mailto:d...@redhat.com>> wrote:
I don't think this works because of option(). This defines the
value to it's default (OFF if no default is given), so the value is
always defined. We can skip using option, but this will break
anyone using any tools to automate their cmake.
What we need is for option() to distinguish between using the
default value and having it configured on.
I can play with this a bit and see if I can get something to work,
but it will be ugly, since cmake doesn't natively support this.
Daniel
On 03/22/2018 10:50 AM, Malahal Naineni wrote:
Here is what I wanted. Let us say there is a compilation feature
called USE_FSAL_GPFS. I want these possibilities:
1. If I enable this feature at the "cmake command line", enable
this. If it can't be enabled due to missing packages, then
please fail cmake!
2. If I disable this feature at the "cmake command line", please
disable it. This is easy.
3. If I neither enable nor disable at the cmake command line,
then it can be auto-enabled if sufficient packages are
installed.
I am not sure if the following works for what I am thinking of
(I added braces for clarity):
if (DEFINED USE_FSAL_GPFS) {
if (USE_FSAL_GPFS) {
case A: admin wants it. Check headers and libs
(or packages). If it can't be enabled, fail.
else () {
case B: admin doesn't want it
}
else () {# not defined by the admin
case C: We want to enable this feature if required
packages are installed.
case D: We don't care, just disable
}
I don't know if DEFINED keyword works the way I want it though.
Note that case A is the only one that fails here.
Regards, Malahal.
On Thu, Mar 22, 2018 at 5:33 PM, Daniel Gryniewicz
<d...@redhat.com <mailto:d...@redhat.com>
<mailto:d...@redhat.com <mailto:d...@redhat.com>>> wrote:
So, there is an option STRICT_PACKAGE that is supposed to
enable
this. It's not fully utilized, but it's mostly there.
The problem is that we can't tell whether the default is
being used
(lots of options are on by default but disable themselves
if the
packages aren't installed) or if the user explicitly turned
them on.
CMake doesn't seem to give us that information, that I've
found. So, instead, we have STRICT_PACKAGE, and you'll have
to explicitly
turn off everything that's on by default but that you don't
want.
If you know of a better way of doing this, then I'm happy
to listen
and help implement it.
Daniel
On 03/22/2018 12:28 AM, Malahal Naineni wrote:
If I specify an option on the cmake command line, I
would like
it to be honoured, if not, simply fail.
Today, cmake only gives
a warning if it can't meet my option's requirements.
Can some
cmake guru fix this first?
On Tue, Mar 20, 2018 at 8:38 PM, Daniel Gryniewicz
<d...@redhat.com <mailto:d...@redhat.com>
<mailto:d...@redhat.com <mailto:d...@redhat.com>>
<mailto:d...@redhat.com <mailto:d...@redhat.com>
<mailto:d...@redhat.com <mailto:d...@redhat.com>>>> wrote:
It's probably a good idea to add the build options
to --version
output, or something. That way we can ask for it
in these
types of
situations. I've added a card to the wishlist for
this.
Daniel
On Tue, Mar 20, 2018 at 9:39 AM, TomK
<tomk...@mdevsys.com <mailto:tomk...@mdevsys.com>
<mailto:tomk...@mdevsys.com
<mailto:tomk...@mdevsys.com>>
<mailto:tomk...@mdevsys.com
<mailto:tomk...@mdevsys.com> <mailto:tomk...@mdevsys.com
<mailto:tomk...@mdevsys.com>>>>
wrote:
> On 3/19/2018 9:54 AM, Frank Filz wrote:
>>>
>>> Solved.
>>>
>>> Here's the solution in case it can help
someone else.
>>>
>>> To get a certain feature in NFS Ganesha, I
had to
compile the V2.6
>>> release from source. When configuring to
compile, idmapd
support got
>>> disabled since packages were missing:
>>>
>>> libnfsidmap-devel-0.25-17.el7.x86_64
>>>
>>> Installed the above package and recompiled
with nfsidmap
support enabled
>>> and this issue went away. Users now show up
properly
off the
NFS mount
>>> on clients.
>>
>>
>> Oh, well that was a simple fix :-)
>>
>> I wonder if we could make changes in our cmake
files to
make it
easier to
>> see when stuff got left out due to missing
packages?
I've been
caught out
>> myself.
>>
>> Frank
>>
> Yep, sure was an easy fix.
>
> Wouldn't mind seeing that. Maybe even a way to
find out
what
options went
> into compiling packages for each distro.
>
>
> --
> Cheers,
> Tom K.
>
-------------------------------------------------------------------------------------
>
> Living on earth is expensive, but it includes a
free
trip around
the sun.
>
