[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Make code compatible for python2 and 3.

2018-03-22 Thread GerritHub 
>From :

supriti.si...@suse.com has uploaded this change for review. ( 
https://review.gerrithub.io/404787


Change subject: Make code compatible for python2 and 3.
..

Make code compatible for python2 and 3.

Compiling the code with DUSE_ADMIN_TOOLS and DUSE_MAN_PAGE,
with python 3 throws error regarding print syntax. In python3,
print is a function. Modify the code accordingly. To keep it
compatible with python2, add "import_future". Also, fixed the
mixed tabs and spaces in glib_dbus_stats.

Change-Id: I1871dd1414ceb3fad9a097c907db133b6a7bc196
Signed-off-by: Supriti Singh 
---
M src/scripts/ganeshactl/Ganesha/glib_dbus_stats.py
M src/scripts/ganeshactl/client_stats_9pOps.py
M src/scripts/ganeshactl/export_stats_9pOps.py
3 files changed, 62 insertions(+), 55 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/87/404787/1
--
To view, visit https://review.gerrithub.io/404787
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I1871dd1414ceb3fad9a097c907db133b6a7bc196
Gerrit-Change-Number: 404787
Gerrit-PatchSet: 1
Gerrit-Owner: supriti.si...@suse.com
--
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

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread Daniel Gryniewicz 
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 > 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 > 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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't dec open_fd_count unless close succeeds

2018-03-22 Thread GerritHub 
>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded this change for review. ( 
https://review.gerrithub.io/404816


Change subject: Don't dec open_fd_count unless close succeeds
..

Don't dec open_fd_count unless close succeeds

Change-Id: I49925c538ad9bd4eb7b00359c1da963a8e7cb3f4
Signed-off-by: Daniel Gryniewicz 
---
M src/FSAL/commonlib.c
1 file changed, 1 insertion(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/16/404816/1
--
To view, visit https://review.gerrithub.io/404816
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I49925c538ad9bd4eb7b00359c1da963a8e7cb3f4
Gerrit-Change-Number: 404816
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz 
--
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

Re: [Nfs-ganesha-devel] Release V2.6.1

2018-03-22 Thread Kaleb S. KEITHLEY 
On 03/20/2018 10:09 AM, Daniel Gryniewicz wrote:
> I'd like to announce the release of the latest stable version of Ganesha: 
> 2.6.1
> 

As a convenience, "community" packages of nfs-ganesha-2.6.1, including
(lib)ntirpc-1.6.2, are provided in or for the following Linux distributions:

* Fedora 28 and 29(rawhide) in the Updates, Updates-Testing, or Rawhide
repositories. Use `dnf` to install. Fedora 27 at [1].

* Debian Stretch/9 and Buster/10 at [1]

* CentOS/RHEL 6 and 7 in the CentOS Storage SIG. For more info on using
the Storage SIG see [2]. You may also get the RPMs from [3] or after a
short testing period from [4]

* Ubuntu Xenial/16.04, Artful/17.10, and Bionic/18.04 in Launchpad at [5]

* SuSE/OpenSuSE SLES12SP3, Leap42.3, SLES15, Leap15, and Tumbleweed in
OBS at [6].

Most packages include all the current actively maintained FSALs,
including FSAL_VFS, FSAL_GPFS, FSAL_GLUSTER, FSAL_CEPH, FSAL_RGW, and
etc. If they don't include the FSAL you want, it's usually because the
platform does not have the necessary prerequisites in the base distribution.

For bugs in nfs-ganesha and ntirpc, open a github issue at [7] or [8]
respectively. For bugs in the Fedora/CentOS/RHEL/SuSE packaging, open a
github issue at [7]. For bugs in the Debian/Ubuntu packaging, open a
github issue at [9]. If in doubt about whether it's a bug in nfs-ganesha
or in the packaging, open a github issue at [7].


[1] https://download.gluster.org/pub/gluster/nfs-ganesha/2.6/2.6.1/
[2] https://wiki.centos.org/SpecialInterestGroup/Storage
[3] https://buildlogs.centos.org/centos/$dist/storage/$arch/gluster-3.13
[4] http://mirror.centos.org/centos/$dist/storage/$arch/gluster-3.13
[5] https://launchpad.net/~gluster/
[6] https://build.opensuse.org/project/subprojects/home:glusterfs
[7] https://github.com/nfs-ganesha/nfs-ganesha/issues
[8] https://github.com/nfs-ganesha/ntirpc/issues
[9] https://github.com/nfs-ganesha/nfs-ganesha-debian/issues



--
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

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread Daniel Gryniewicz 
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 > 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

>> 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 
     >>
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.
      >

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread Daniel Gryniewicz 
No, we can't.  I'm working on a set of macros that make this work (as 
far as I can tell) and aren't *too* ugly.  Hopefully, this will work out.


Daniel

On 03/22/2018 12:13 PM, Malahal Naineni wrote:
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 > 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

>> 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
         
>
         

         >
                On 3/19/2018 9:54 AM, Frank Filz wrote:
               >>>
               >>> Solved.

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread Malahal Naineni 
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  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 > > 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
>> 
>> >> 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 > 
>>  >>
>>
>> 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

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread Malahal Naineni 
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  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 > > 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 > > 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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add new CMake option code

2018-03-22 Thread GerritHub 
>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded this change for review. ( 
https://review.gerrithub.io/404945


Change subject: Add new CMake option code
..

Add new CMake option code

CMake options were either on or off, and no way to tell if they were
using the default value or if they were specified on the command line.
This made it extremely difficult to error out if something was specified
on the command line but the dependencies were not installed.

Add a new pair of macros for option processing:
- goption() is a replacement for option(), and it records the default
  value specially
- gopt_check() should be called before using the option, and it
  determins whether or not the default was used, and sets _REQUIRED
  as a result.  This can be used to error out if the option was given on
  the command line.

Most options are converted to this new API.

Change-Id: I83609375ddc27648bc6eb2bb9fe73848f571a309
Signed-off-by: Daniel Gryniewicz 
---
M src/CMakeLists.txt
A src/cmake/goption.cmake
R src/cmake/modules/FindCEPHFS.cmake
M src/cmake/modules/FindWBclient.cmake
M src/test/CMakeLists.txt
5 files changed, 285 insertions(+), 147 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/45/404945/1
--
To view, visit https://review.gerrithub.io/404945
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I83609375ddc27648bc6eb2bb9fe73848f571a309
Gerrit-Change-Number: 404945
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz 
--
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

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-22 Thread TomK 

On 3/22/2018 12:50 PM, Daniel Gryniewicz wrote:
A side note, happy to test for you guy's once you have this done.

No, we can't.  I'm working on a set of macros that make this work (as 
far as I can tell) and aren't *too* ugly.  Hopefully, this will work out.


Daniel

On 03/22/2018 12:13 PM, Malahal Naineni wrote:
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 > 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
    
    >> 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
         
    >
         
    
         >

             

[Nfs-ganesha-devel] Review request https://review.gerrithub.io/#/c/393642/

2018-03-22 Thread Girjesh Rajoria 
Hi Malahal,

Since this change has an impact on FSAL_GPFS, please review this change:
https://review.gerrithub.io/#/c/393642/



-- 
Thanks
Girjesh
--
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