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> 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>> 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>>> 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>>>
>>
>> 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.
>> >
>>
>>
>>
>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
