Running Test Scripts without CMake Environment Variables

Running Test Scripts without CMake Environment Variables

[Ali Maredia]

Ceph community,

Recently certain tests that are run in `make check` (one's that end in .sh and a handful of others) were changed to remove relative paths and hard coded directories (".libs" was littered throughout the codebase). 

These test scripts pass when you run `make check` because of preset environment variables in CTest and in src/Makefile.am (CEPH_BIN, CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are meant to replace the relative paths from before. However running these tests by themselves after an autotools build without setting those variables before hand will result in failures. 

I understand how these recent changes disrupt developers workflows and plan on issuing a fix that defines those environment variables according to which build system you build with ASAP.

Finally I strongly encourage developers to transition to using CMake and CTest (run ctest -V -R {test_name} from CMAKE_BINARY_DIR), and submit fixes and other contributions.
 
-Ali

Re: Running Test Scripts without CMake Environment Variables

[Willem Jan Withagen]

On 18-4-2016 23:53, Ali Maredia wrote:
> Ceph community,
>
> Recently certain tests that are run in `make check` (one's that end
> in .sh and a handful of others) were changed to remove relative paths
> and hard coded directories (".libs" was littered throughout the
> codebase).
>
> These test scripts pass when you run `make check` because of preset
> environment variables in CTest and in src/Makefile.am (CEPH_BIN,
> CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are meant to replace
>  the relative paths from before. However running these tests by
> themselves after an autotools build without setting those variables
> before hand will result in failures.
>
> I understand how these recent changes disrupt developers workflows
> and plan on issuing a fix that defines those environment variables
> according to which build system you build with ASAP.
>
> Finally I strongly encourage developers to transition to using CMake
>  and CTest (run ctest -V -R {test_name} from CMAKE_BINARY_DIR), and
> submit fixes and other contributions.

Hi Ali,

I'm trying to get a port for FreeBSD working, and started from make(gmake)
because Cmake did not work that well when I started.
And as such I do always follow the regular pattern and just use the
makefiles as they are. Just because running Make at the top level is a
rather long process. So I keep a script where I run the tests that are
still giving me faults. And it does complete different things from what
make does. Because make assuems that things are going to complete with
success, but in my case I'm actually expecting things to go wrong. :) So
then I start collecting cores and logfiles for post-mortum analysis.

So I'd like to be able to run every test on its own.
And even when I would migrate to Cmake, I would still want to be able to
do that.
So they even have to work if you do not use a build system, it would be
very nice if things are backwards compatible.

And yes, I also want to go to Cmake, because autobuild it an odd bucket
of bits, but preferably not right now.

Thanx,
--WjW

Re: Running Test Scripts without CMake Environment Variables

[Matt Benjamin]

Hi Willem,

What are the main barriers to using CMake on FreeBSD?  My only data point about it is nfs-ganesha builds, but my understanding has been, it's worked for that for a few years.

Matt

----- Original Message -----
> From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: "Ali Maredia" <amaredia@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Tuesday, April 19, 2016 4:07:06 AM
> Subject: Re: Running Test Scripts without CMake Environment Variables
> 
> On 18-4-2016 23:53, Ali Maredia wrote:
> > Ceph community,
> >
> > Recently certain tests that are run in `make check` (one's that end
> > in .sh and a handful of others) were changed to remove relative paths
> > and hard coded directories (".libs" was littered throughout the
> > codebase).
> >
> > These test scripts pass when you run `make check` because of preset
> > environment variables in CTest and in src/Makefile.am (CEPH_BIN,
> > CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are meant to replace
> >  the relative paths from before. However running these tests by
> > themselves after an autotools build without setting those variables
> > before hand will result in failures.
> >
> > I understand how these recent changes disrupt developers workflows
> > and plan on issuing a fix that defines those environment variables
> > according to which build system you build with ASAP.
> >
> > Finally I strongly encourage developers to transition to using CMake
> >  and CTest (run ctest -V -R {test_name} from CMAKE_BINARY_DIR), and
> > submit fixes and other contributions.
> 
> Hi Ali,
> 
> I'm trying to get a port for FreeBSD working, and started from make(gmake)
> because Cmake did not work that well when I started.
> And as such I do always follow the regular pattern and just use the
> makefiles as they are. Just because running Make at the top level is a
> rather long process. So I keep a script where I run the tests that are
> still giving me faults. And it does complete different things from what
> make does. Because make assuems that things are going to complete with
> success, but in my case I'm actually expecting things to go wrong. :) So
> then I start collecting cores and logfiles for post-mortum analysis.
> 
> So I'd like to be able to run every test on its own.
> And even when I would migrate to Cmake, I would still want to be able to
> do that.
> So they even have to work if you do not use a build system, it would be
> very nice if things are backwards compatible.
> 
> And yes, I also want to go to Cmake, because autobuild it an odd bucket
> of bits, but preferably not right now.
> 
> Thanx,
> --WjW
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: Running Test Scripts without CMake Environment Variables

[Willem Jan Withagen]

On 19-4-2016 15:59, Matt Benjamin wrote:
> Hi Willem,
> 
> What are the main barriers to using CMake on FreeBSD?  My only data
> point about it is nfs-ganesha builds, but my understanding has been,
> it's worked for that for a few years.

Hi Matt,

To name a few:

I did not understand that Cmake was the direction of Ceph when I started
last November...

When I started porting I got a few error messages from Cmake. And given
the fact that I'm more familiar with (g)make and autobuild, I chose that
route. I know Cmake exists, and that is about it. So that is again a
tool/language to learn. Autobuild is also far from perfect, but whacking
at it is relatively easy.

It seemed to know little about Clang, if I remember correctly, but it is
like 6 months ago.

Before investing "porting"/migrating to another build tool I prefer to
have at least a working testset. So my focus is mostly on that.

So no real practical ones, just a matter of my current choices.

But perhaps I should give it a try again and see what comes of it..

--WjW

> Matt
> 
> ----- Original Message -----
>> From: "Willem Jan Withagen" <wjw@digiware.nl> To: "Ali Maredia"
>> <amaredia@redhat.com>, ceph-devel@vger.kernel.org Sent: Tuesday,
>> April 19, 2016 4:07:06 AM Subject: Re: Running Test Scripts without
>> CMake Environment Variables
>> 
>> On 18-4-2016 23:53, Ali Maredia wrote:
>>> Ceph community,
>>> 
>>> Recently certain tests that are run in `make check` (one's that
>>> end in .sh and a handful of others) were changed to remove
>>> relative paths and hard coded directories (".libs" was littered
>>> throughout the codebase).
>>> 
>>> These test scripts pass when you run `make check` because of
>>> preset environment variables in CTest and in src/Makefile.am
>>> (CEPH_BIN, CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are
>>> meant to replace the relative paths from before. However running
>>> these tests by themselves after an autotools build without
>>> setting those variables before hand will result in failures.
>>> 
>>> I understand how these recent changes disrupt developers
>>> workflows and plan on issuing a fix that defines those
>>> environment variables according to which build system you build
>>> with ASAP.
>>> 
>>> Finally I strongly encourage developers to transition to using
>>> CMake and CTest (run ctest -V -R {test_name} from
>>> CMAKE_BINARY_DIR), and submit fixes and other contributions.
>> 
>> Hi Ali,
>> 
>> I'm trying to get a port for FreeBSD working, and started from
>> make(gmake) because Cmake did not work that well when I started. 
>> And as such I do always follow the regular pattern and just use
>> the makefiles as they are. Just because running Make at the top
>> level is a rather long process. So I keep a script where I run the
>> tests that are still giving me faults. And it does complete
>> different things from what make does. Because make assuems that
>> things are going to complete with success, but in my case I'm
>> actually expecting things to go wrong. :) So then I start
>> collecting cores and logfiles for post-mortum analysis.
>> 
>> So I'd like to be able to run every test on its own. And even when
>> I would migrate to Cmake, I would still want to be able to do
>> that. So they even have to work if you do not use a build system,
>> it would be very nice if things are backwards compatible.
>> 
>> And yes, I also want to go to Cmake, because autobuild it an odd
>> bucket of bits, but preferably not right now.
>> 
>> Thanx, --WjW -- To unsubscribe from this list: send the line
>> "unsubscribe ceph-devel" in the body of a message to
>> majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>> 
> 

Re: Running Test Scripts without CMake Environment Variables

[Matt Benjamin]

Hi Willem,

I think most devs now believe it's worth switching to cmake, mainly for build performance.

I recall having issues compiling with Clang++ recently too--but for me, the issues seemed to be
related to leveldb and rocksdb linkage.  I know that a number of us would like Clang++ builds
to be generally supported, not something that you have to maintain yourself just for FreeBSD.

When you do experiment with cmake again, I'm sure folks will try to be helpful with
specific issues.

Matt

----- Original Message -----
> From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Ali Maredia" <amaredia@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Tuesday, April 19, 2016 1:57:16 PM
> Subject: Re: Running Test Scripts without CMake Environment Variables
> 
> On 19-4-2016 15:59, Matt Benjamin wrote:
> > Hi Willem,
> > 
> > What are the main barriers to using CMake on FreeBSD?  My only data
> > point about it is nfs-ganesha builds, but my understanding has been,
> > it's worked for that for a few years.
> 
> Hi Matt,
> 
> To name a few:
> 
> I did not understand that Cmake was the direction of Ceph when I started
> last November...
> 
> When I started porting I got a few error messages from Cmake. And given
> the fact that I'm more familiar with (g)make and autobuild, I chose that
> route. I know Cmake exists, and that is about it. So that is again a
> tool/language to learn. Autobuild is also far from perfect, but whacking
> at it is relatively easy.
> 
> It seemed to know little about Clang, if I remember correctly, but it is
> like 6 months ago.
> 
> Before investing "porting"/migrating to another build tool I prefer to
> have at least a working testset. So my focus is mostly on that.
> 
> So no real practical ones, just a matter of my current choices.
> 
> But perhaps I should give it a try again and see what comes of it..
> 
> --WjW
> 
> > Matt
> > 
> > ----- Original Message -----
> >> From: "Willem Jan Withagen" <wjw@digiware.nl> To: "Ali Maredia"
> >> <amaredia@redhat.com>, ceph-devel@vger.kernel.org Sent: Tuesday,
> >> April 19, 2016 4:07:06 AM Subject: Re: Running Test Scripts without
> >> CMake Environment Variables
> >> 
> >> On 18-4-2016 23:53, Ali Maredia wrote:
> >>> Ceph community,
> >>> 
> >>> Recently certain tests that are run in `make check` (one's that
> >>> end in .sh and a handful of others) were changed to remove
> >>> relative paths and hard coded directories (".libs" was littered
> >>> throughout the codebase).
> >>> 
> >>> These test scripts pass when you run `make check` because of
> >>> preset environment variables in CTest and in src/Makefile.am
> >>> (CEPH_BIN, CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are
> >>> meant to replace the relative paths from before. However running
> >>> these tests by themselves after an autotools build without
> >>> setting those variables before hand will result in failures.
> >>> 
> >>> I understand how these recent changes disrupt developers
> >>> workflows and plan on issuing a fix that defines those
> >>> environment variables according to which build system you build
> >>> with ASAP.
> >>> 
> >>> Finally I strongly encourage developers to transition to using
> >>> CMake and CTest (run ctest -V -R {test_name} from
> >>> CMAKE_BINARY_DIR), and submit fixes and other contributions.
> >> 
> >> Hi Ali,
> >> 
> >> I'm trying to get a port for FreeBSD working, and started from
> >> make(gmake) because Cmake did not work that well when I started.
> >> And as such I do always follow the regular pattern and just use
> >> the makefiles as they are. Just because running Make at the top
> >> level is a rather long process. So I keep a script where I run the
> >> tests that are still giving me faults. And it does complete
> >> different things from what make does. Because make assuems that
> >> things are going to complete with success, but in my case I'm
> >> actually expecting things to go wrong. :) So then I start
> >> collecting cores and logfiles for post-mortum analysis.
> >> 
> >> So I'd like to be able to run every test on its own. And even when
> >> I would migrate to Cmake, I would still want to be able to do
> >> that. So they even have to work if you do not use a build system,
> >> it would be very nice if things are backwards compatible.
> >> 
> >> And yes, I also want to go to Cmake, because autobuild it an odd
> >> bucket of bits, but preferably not right now.
> >> 
> >> Thanx, --WjW -- To unsubscribe from this list: send the line
> >> "unsubscribe ceph-devel" in the body of a message to
> >> majordomo@vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >> 
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: Running Test Scripts without CMake Environment Variables

[Willem Jan Withagen]

On 20-4-2016 06:12, Matt Benjamin wrote:
> Hi Willem,
> 
> I think most devs now believe it's worth switching to cmake, mainly for build performance.
> 
> I recall having issues compiling with Clang++ recently too--but for me, the issues seemed to be
> related to leveldb and rocksdb linkage.  I know that a number of us would like Clang++ builds
> to be generally supported, not something that you have to maintain yourself just for FreeBSD.
> 
> When you do experiment with cmake again, I'm sure folks will try to be helpful with
> specific issues.

The run-cmake-check.sh would be the entry-point?
That has to be augmented to do "the right thing" for FreeBSD.

It does assume that rbd is available. Which certainly is not the case on
FreeBSD for the time to come. So the Cmake stuff needs to be able to
take that onto all of the other code...

--WjW

> Matt
> 
> ----- Original Message -----
>> From: "Willem Jan Withagen" <wjw@digiware.nl>
>> To: "Matt Benjamin" <mbenjamin@redhat.com>
>> Cc: "Ali Maredia" <amaredia@redhat.com>, ceph-devel@vger.kernel.org
>> Sent: Tuesday, April 19, 2016 1:57:16 PM
>> Subject: Re: Running Test Scripts without CMake Environment Variables
>>
>> On 19-4-2016 15:59, Matt Benjamin wrote:
>>> Hi Willem,
>>>
>>> What are the main barriers to using CMake on FreeBSD?  My only data
>>> point about it is nfs-ganesha builds, but my understanding has been,
>>> it's worked for that for a few years.
>>
>> Hi Matt,
>>
>> To name a few:
>>
>> I did not understand that Cmake was the direction of Ceph when I started
>> last November...
>>
>> When I started porting I got a few error messages from Cmake. And given
>> the fact that I'm more familiar with (g)make and autobuild, I chose that
>> route. I know Cmake exists, and that is about it. So that is again a
>> tool/language to learn. Autobuild is also far from perfect, but whacking
>> at it is relatively easy.
>>
>> It seemed to know little about Clang, if I remember correctly, but it is
>> like 6 months ago.
>>
>> Before investing "porting"/migrating to another build tool I prefer to
>> have at least a working testset. So my focus is mostly on that.
>>
>> So no real practical ones, just a matter of my current choices.
>>
>> But perhaps I should give it a try again and see what comes of it..
>>
>> --WjW
>>
>>> Matt
>>>
>>> ----- Original Message -----
>>>> From: "Willem Jan Withagen" <wjw@digiware.nl> To: "Ali Maredia"
>>>> <amaredia@redhat.com>, ceph-devel@vger.kernel.org Sent: Tuesday,
>>>> April 19, 2016 4:07:06 AM Subject: Re: Running Test Scripts without
>>>> CMake Environment Variables
>>>>
>>>> On 18-4-2016 23:53, Ali Maredia wrote:
>>>>> Ceph community,
>>>>>
>>>>> Recently certain tests that are run in `make check` (one's that
>>>>> end in .sh and a handful of others) were changed to remove
>>>>> relative paths and hard coded directories (".libs" was littered
>>>>> throughout the codebase).
>>>>>
>>>>> These test scripts pass when you run `make check` because of
>>>>> preset environment variables in CTest and in src/Makefile.am
>>>>> (CEPH_BIN, CEPH_ROOT, CEPH_LIB, CEPH_BUILD_DIR, etc.) that are
>>>>> meant to replace the relative paths from before. However running
>>>>> these tests by themselves after an autotools build without
>>>>> setting those variables before hand will result in failures.
>>>>>
>>>>> I understand how these recent changes disrupt developers
>>>>> workflows and plan on issuing a fix that defines those
>>>>> environment variables according to which build system you build
>>>>> with ASAP.
>>>>>
>>>>> Finally I strongly encourage developers to transition to using
>>>>> CMake and CTest (run ctest -V -R {test_name} from
>>>>> CMAKE_BINARY_DIR), and submit fixes and other contributions.
>>>>
>>>> Hi Ali,
>>>>
>>>> I'm trying to get a port for FreeBSD working, and started from
>>>> make(gmake) because Cmake did not work that well when I started.
>>>> And as such I do always follow the regular pattern and just use
>>>> the makefiles as they are. Just because running Make at the top
>>>> level is a rather long process. So I keep a script where I run the
>>>> tests that are still giving me faults. And it does complete
>>>> different things from what make does. Because make assuems that
>>>> things are going to complete with success, but in my case I'm
>>>> actually expecting things to go wrong. :) So then I start
>>>> collecting cores and logfiles for post-mortum analysis.
>>>>
>>>> So I'd like to be able to run every test on its own. And even when
>>>> I would migrate to Cmake, I would still want to be able to do
>>>> that. So they even have to work if you do not use a build system,
>>>> it would be very nice if things are backwards compatible.
>>>>
>>>> And yes, I also want to go to Cmake, because autobuild it an odd
>>>> bucket of bits, but preferably not right now.
>>>>
>>>> Thanx, --WjW -- To unsubscribe from this list: send the line
>>>> "unsubscribe ceph-devel" in the body of a message to
>>>> majordomo@vger.kernel.org More majordomo info at
>>>> http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

Re: Running Test Scripts without CMake Environment Variables

[Willem Jan Withagen]

On 20-4-2016 06:12, Matt Benjamin wrote:
> Hi Willem,
>
> I think most devs now believe it's worth switching to cmake, mainly
> for build performance.
>
> I recall having issues compiling with Clang++ recently too--but for
> me, the issues seemed to be related to leveldb and rocksdb linkage.
> I know that a number of us would like Clang++ builds to be generally
> supported, not something that you have to maintain yourself just for
> FreeBSD.
>
> When you do experiment with cmake again, I'm sure folks will try to
> be helpful with specific issues.

'mmmm, lets give it a shot....
Created a separate WIP for it
And hope that Cmake guys lurk here

FreeBSD does have not udev, something similar is devd but it is
certainly not used to the extend
that udev it is used under Linux, as far as I can tell.

-- Not Found libudev: UDEV_LIBRARY-NOTFOUND
CMake Error at
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
   Could NOT find udev (missing: UDEV_LIBRARIES UDEV_INCLUDE_DIR)
Call Stack (most recent call first):
   /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
(_FPHSA_FAILURE_MESSAGE)
   cmake/modules/Findudev.cmake:52 (find_package_handle_standard_args)
   CMakeLists.txt:129 (find_package)

And as for UUIDs I'm using a different library from a package
misc/e2fsprogs-libuuid and link with -luuid.

These are my full setting I use before running autogen.sh and configure:
     CWARN=""
     COPTIMIZE="-g -O0 -fno-omit-frame-pointer"
     CLANGWARN="-Wno-unused-local-typedef -Wno-mismatched-tags 
-Wno-macro-redefined -Wno-unused-function -Wno-unused-label 
-Wno-undefined-bool-conversion -Wno-unused-private-field 
-Wno-unused-local-typedef -Wno-uninitialized -Wno-gnu-designator 
-Wno-inconsistent-missing-override -Wno-deprecated-declarations 
-Wno-parentheses -Wno-missing-braces"
     CFLAGS="${COPTIMIZE} -I/usr/local/include ${CWARN} ${CLANGWARN}"
     CXXFLAGS="${COPTIMIZE} -DGTEST_USE_OWN_TR1_TUPLE=1 
-I/usr/local/include ${CWARN} ${CLANGWARN}"
     LDFLAGS="-g ${LDFLAGS} -L/usr/local/lib -export-dynamic -luuid -lcxxrt"
     FREEBSD_CONFIGURE_FLAGS="
       --disable-silent-rules
       --disable-gitversion
       --with-debug
       --with-rados
       --without-rbd
       --with-radosgw
       --with-radosstriper
       --with-mon
       --with-osd
       --with-mds
       --with-radosgw
       --with-nss
       --without-tcmalloc
       --without-libaio
       --without-libxfs
       --without-fuse
       --without-lttng
       --with-libzfs=no
       --without-rocksdb
       --with-cephfs=no
         "
With what incantations do I glue the above in the Cmake build process?

Thanx,
--WjW