All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem Jan Withagen <wjw@digiware.nl>
To: Ali Maredia <amaredia@redhat.com>, ceph-devel@vger.kernel.org
Subject: Re: Running Test Scripts without CMake Environment Variables
Date: Tue, 19 Apr 2016 10:07:06 +0200	[thread overview]
Message-ID: <5715E72A.2040202@digiware.nl> (raw)
In-Reply-To: <545596550.14429240.1461016414390.JavaMail.zimbra@redhat.com>

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

  reply	other threads:[~2016-04-19  8:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <75379254.14369376.1461010122306.JavaMail.zimbra@redhat.com>
2016-04-18 21:53 ` Running Test Scripts without CMake Environment Variables Ali Maredia
2016-04-19  8:07   ` Willem Jan Withagen [this message]
2016-04-19 13:59     ` Matt Benjamin
2016-04-19 17:57       ` Willem Jan Withagen
2016-04-20  4:12         ` Matt Benjamin
2016-04-20  9:51           ` Willem Jan Withagen
2016-04-21  9:11           ` Willem Jan Withagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5715E72A.2040202@digiware.nl \
    --to=wjw@digiware.nl \
    --cc=amaredia@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.