<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/22/2014 05:22 PM, Luis Pabón
wrote:<br>
</div>
<blockquote cite="mid:53CE506A.7050703@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Lala,<br>
No problem at all, I just want to make sure that developers
understand the importance of the tool. On the topic of RPMs, they
have a really cool section called "%check", which is currently
being used to run the unit tests after the glusterfs RPM is
created. Normally developers test only on certain systems and
certain architectures, but by having the "%check" section, we can
guarantee a level of quality when an RPM is created on an
architecture or operating system version which is not normally
used for development. This actually worked really well for
cmockery2 when the RPM was first introduced to Fedora. The %check
section ran the unit tests on two architectures that I do not
have, and both of them found issues on ARM32 and s390
architectures. Without the %check section, cmockery2 would have
been released and not been able to have been used. This is why
cmockery2 is set in the "BuildRequires" section.<br>
<br>
</blockquote>
<br>
Awesome!, now it make perfect sense to run these units tests during
RPM building. Thanks Luis.<br>
<br>
<blockquote cite="mid:53CE506A.7050703@redhat.com" type="cite"> <br>
<br>
<div class="moz-cite-prefix">On 07/22/2014 07:34 AM, Lalatendu
Mohanty wrote:<br>
</div>
<blockquote cite="mid:53CE4C2E.5020503@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 07/22/2014 04:35 PM, Luis Pabón
wrote:<br>
</div>
<blockquote cite="mid:53CE4589.8050108@redhat.com" type="cite">I
understand that when something is new and different, it is
most likely blamed for anything wrong that happens. I highly
propose that we do not do this, and instead work to learn more
about the tool. <br>
<br>
Cmockery2 is a tool that is important as the compiler. It
provides an extremely easy method to determine the quality of
the software after it has been constructed, and therefore it
has been made to be a requirement of the build. Making it
optional undermines its importance, and could in turn make it
useless. <br>
<br>
</blockquote>
<br>
Hey Luis,<br>
<br>
Th intention was not to undermine or give less importance to
Cmockery2. Sorry if it looked like that. <br>
<br>
However I was thinking from a flexibility point of view. I am
assuming in future, it would be part of upstream regression test
suite. So each patch will go through full unit testing
by-default. So when somebody is creating RPMs from
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
pristine sources, we should be able to do that without Cmockery2
because the tests were already ran through Jenkins/gerrit. <br>
<br>
The question is do we need Cmockery every-time we compile
glusterfs source? if the answer is yes, then I am fine with
current code.<br>
<br>
<blockquote cite="mid:53CE4589.8050108@redhat.com" type="cite">Cmockery2
is available for all supported EPEL/Fedora versions. For any
other distribution or operating system, it takes about 3 mins
to download and compile. <br>
<br>
Please let me know if you have any other questions. <br>
<br>
- Luis <br>
<br>
On 07/22/2014 02:23 AM, Lalatendu Mohanty wrote: <br>
<blockquote type="cite">On 07/21/2014 10:48 PM, Harshavardhana
wrote: <br>
<blockquote type="cite">Cmockery2 is a hard dependency
before GlusterFS can be compiled in <br>
upstream master now - we could make it conditional <br>
and enable if necessary? since we know we do not have the
cmockery2 <br>
packages available on all systems? <br>
</blockquote>
<br>
+1, we need to make it conditional and enable it if
necessary. I am also not sure if we have "cmockery2-devel"
in el5, el6. If not Build will fail. <br>
<br>
<blockquote type="cite">On Mon, Jul 21, 2014 at 10:16 AM,
Luis Pabon <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:lpabon@redhat.com"><lpabon@redhat.com></a>
wrote: <br>
<blockquote type="cite">Niels you are correct. Let me take
a look. <br>
<br>
Luis <br>
<br>
<br>
-----Original Message----- <br>
From: Niels de Vos [<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>]
<br>
Received: Monday, 21 Jul 2014, 10:41AM <br>
To: Luis Pabon [<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:lpabon@redhat.com">lpabon@redhat.com</a>]
<br>
CC: Anders Blomdell [<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:anders.blomdell@control.lth.se">anders.blomdell@control.lth.se</a>];
<br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>
<br>
Subject: Re: [Gluster-devel] Cmockery2 in GlusterFS <br>
<br>
<br>
On Mon, Jul 21, 2014 at 04:27:18PM +0200, Anders
Blomdell wrote: <br>
<blockquote type="cite">On 2014-07-21 16:17, Anders
Blomdell wrote: <br>
<blockquote type="cite">On 2014-07-20 16:01, Niels de
Vos wrote: <br>
<blockquote type="cite">On Fri, Jul 18, 2014 at
02:52:18PM -0400, Luis Pabón wrote: <br>
<blockquote type="cite">Hi all, <br>
A few months ago, the unit test framework
based on cmockery2 was <br>
in the repo for a little while, then removed
while we improved the <br>
packaging method. Now support for cmockery2 ( <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://review.gluster.org/#/c/7538/">http://review.gluster.org/#/c/7538/</a>
) has been merged into the repo <br>
again. This will most likely require you to
install cmockery2 on <br>
your development systems by doing the following:
<br>
<br>
* Fedora/EPEL: <br>
$ sudo yum -y install cmockery2-devel <br>
<br>
* All other systems please visit the following
page: <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/lpabon/cmockery2/blob/master/doc/usage.md#installation">https://github.com/lpabon/cmockery2/blob/master/doc/usage.md#installation</a>
<br>
<br>
Here is also some information about Cmockery2
and how to use it: <br>
<br>
* Introduction to Unit Tests in C Presentation:
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://slides-lpabon.rhcloud.com/feb24_glusterfs_unittest.html#/">http://slides-lpabon.rhcloud.com/feb24_glusterfs_unittest.html#/</a>
<br>
* Cmockery2 Usage Guide: <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/lpabon/cmockery2/blob/master/doc/usage.md">https://github.com/lpabon/cmockery2/blob/master/doc/usage.md</a>
<br>
* Using Cmockery2 with GlusterFS: <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/gluster/glusterfs/blob/master/doc/hacker-guide/en-US/markdown/unittest.md">https://github.com/gluster/glusterfs/blob/master/doc/hacker-guide/en-US/markdown/unittest.md</a>
<br>
<br>
<br>
When starting out writing unit tests, I would
suggest writing unit <br>
tests for non-xlator interface files when you
start. Once you feel <br>
more comfortable writing unit tests, then move
to writing them for <br>
the xlators interface files. <br>
</blockquote>
Awesome, many thanks! I'd like to add some
unittests for the RPC and <br>
NFS <br>
layer. Several functions (like ip-address/netmask
matching for ACLs) <br>
look very suitable. <br>
<br>
Did you have any particular functions in mind that
you would like to <br>
see <br>
unittests for? If so, maybe you can file some bugs
for the different <br>
tests so that we won't forget about it? Depending
on the tests, these <br>
bugs may get the EasyFix keyword if there is a
clear description and <br>
some pointers to examples. <br>
</blockquote>
Looks like parts of cmockery was forgotten in
glusterfs.spec.in: <br>
<br>
# rpm -q -f `which gluster` <br>
glusterfs-cli-3.7dev-0.9.git5b8de97.fc20.x86_64 <br>
# ldd `which gluster` <br>
linux-vdso.so.1 => (0x00007ffff4dfe000) <br>
libglusterfs.so.0 =>
/lib64/libglusterfs.so.0 (0x00007fe034cc4000) <br>
libreadline.so.6 => /lib64/libreadline.so.6
(0x00007fe034a7d000) <br>
libncurses.so.5 => /lib64/libncurses.so.5
(0x00007fe034856000) <br>
libtinfo.so.5 => /lib64/libtinfo.so.5
(0x00007fe03462c000) <br>
libgfxdr.so.0 => /lib64/libgfxdr.so.0
(0x00007fe034414000) <br>
libgfrpc.so.0 => /lib64/libgfrpc.so.0
(0x00007fe0341f8000) <br>
libxml2.so.2 => /lib64/libxml2.so.2
(0x00007fe033e8f000) <br>
libz.so.1 => /lib64/libz.so.1
(0x00007fe033c79000) <br>
libm.so.6 => /lib64/libm.so.6
(0x00007fe033971000) <br>
libdl.so.2 => /lib64/libdl.so.2
(0x00007fe03376d000) <br>
libcmockery.so.0 => not found <br>
libpthread.so.0 => /lib64/libpthread.so.0
(0x00007fe03354f000) <br>
libcrypto.so.10 => /lib64/libcrypto.so.10
(0x00007fe033168000) <br>
libc.so.6 => /lib64/libc.so.6
(0x00007fe032da9000) <br>
libcmockery.so.0 => not found <br>
libcmockery.so.0 => not found <br>
libcmockery.so.0 => not found <br>
liblzma.so.5 => /lib64/liblzma.so.5
(0x00007fe032b82000) <br>
/lib64/ld-linux-x86-64.so.2
(0x00007fe0351f1000) <br>
<br>
Should I file a bug report or could someone on the
fast-lane fix this? <br>
</blockquote>
My bad (installation with --nodeps --force :-() <br>
</blockquote>
Actually, I was not expecting a dependency on cmockery2.
My <br>
understanding was that only some temporary
test-applications would be <br>
linked with libcmockery and not any binaries that would
get packaged in <br>
the RPMs. <br>
<br>
Luis, could you clarify that? <br>
<br>
Thanks, <br>
Niels <br>
<br>
_______________________________________________ <br>
Gluster-devel mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>