[LTP] New test?

[LTP] New test?

[Jiří Paleček]

Hello,

I've decided to create a test for the rt_sigwaitinfo syscall. There are  
other functions with similar interface (defined by POSIX) in libc -  
particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo  
test could easily tests these too, so I wonder whether we want to test  
these too, and if yes, whether these tests can be located in the same  
executable.

Regards
     Jiri Palecek

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Subrata Modak]

Hey Jiri,

On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote: 
> Hello,
> 
> I've decided to create a test for the rt_sigwaitinfo syscall. There are  
> other functions with similar interface (defined by POSIX) in libc -  
> particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo  

The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.

> test could easily tests these too, so I wonder whether we want to test  
> these too, and if yes, whether these tests can be located in the same  
> executable.

If you already have the logic to write the above tests, then please
create separate tests for sigwait, sigtimedwait and sigwaitinfo
(separate directories as well), and separate for rt_sigwaitinfo syscall.

Regards--
Subrata

> 
> Regards
>      Jiri Palecek
> 


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Subrata Modak]

Jiri,

Any further thoughts on this ?

Regards--
Subrata

On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote: 
> Hey Jiri,
> 
> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote: 
> > Hello,
> > 
> > I've decided to create a test for the rt_sigwaitinfo syscall. There are  
> > other functions with similar interface (defined by POSIX) in libc -  
> > particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo  
> 
> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
> 
> > test could easily tests these too, so I wonder whether we want to test  
> > these too, and if yes, whether these tests can be located in the same  
> > executable.
> 
> If you already have the logic to write the above tests, then please
> create separate tests for sigwait, sigtimedwait and sigwaitinfo
> (separate directories as well), and separate for rt_sigwaitinfo syscall.
> 
> Regards--
> Subrata
> 
> > 
> > Regards
> >      Jiri Palecek
> > 
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Jiří Paleček]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak  
<subrata@linux.vnet.ibm.com> wrote:

> Jiri,
>
> Any further thoughts on this ?

Yes, see the attachment.

I created the directories for the different tests (rt_sigtimedwait,  
sigwaitinfo etc.), but to avoid copy-pasting the code, they share the same  
source. Please, tell me if that is OK.

Regards
     Jiri Palecek
> On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote:
>> Hey Jiri,
>>
>> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote:
>> > Hello,
>> >
>> > I've decided to create a test for the rt_sigwaitinfo syscall. There  
>> are
>> > other functions with similar interface (defined by POSIX) in libc -
>> > particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo
>>
>> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
>>
>> > test could easily tests these too, so I wonder whether we want to test
>> > these too, and if yes, whether these tests can be located in the same
>> > executable.
>>
>> If you already have the logic to write the above tests, then please
>> create separate tests for sigwait, sigtimedwait and sigwaitinfo
>> (separate directories as well), and separate for rt_sigwaitinfo syscall.
>>
>> Regards--
>> Subrata
>>
>> >
>> > Regards
>> >      Jiri Palecek
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and  
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Ltp-list mailing list
>> Ltp-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ltp-list
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[-- Attachment #2: sigwaitinfo.patch --]
[-- Type: application/octet-stream, Size: 19774 bytes --]

commit 18b4011a52dc915f1780505c6a529d8aed21aea9
Author: Jiri Palecek <jirka@debian.(none)>
Date:   Tue Oct 6 23:26:44 2009 +0200

    New sigwaitinfo test

diff --git a/testcases/kernel/syscalls/rt_sigtimedwait/Makefile b/testcases/kernel/syscalls/rt_sigtimedwait/Makefile
new file mode 100644
index 0000000..b0d672b
--- /dev/null
+++ b/testcases/kernel/syscalls/rt_sigtimedwait/Makefile
@@ -0,0 +1,34 @@
+#
+#  Copyright (c) International Business Machines  Corp., 2009
+#
+#  This program is free software;  you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY;  without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+#  the GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program;  if not, write to the Free Software
+#  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+
+CFLAGS += -I../../../../include -Wall -O2 -DTEST_RT_SIGTIMEDWAIT
+LDLIBS += -L../../../../lib -lltp 
+
+SRCS    = $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS)) rt_sigtimedwait01
+
+all: $(TARGETS)
+
+rt_sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
+	$(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
+
+install:
+	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
+
+clean:
+	rm -f $(TARGETS)
diff --git a/testcases/kernel/syscalls/sigtimedwait/Makefile b/testcases/kernel/syscalls/sigtimedwait/Makefile
new file mode 100644
index 0000000..a750d7a
--- /dev/null
+++ b/testcases/kernel/syscalls/sigtimedwait/Makefile
@@ -0,0 +1,34 @@
+#
+#  Copyright (c) International Business Machines  Corp., 2009
+#
+#  This program is free software;  you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY;  without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+#  the GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program;  if not, write to the Free Software
+#  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+
+CFLAGS += -I../../../../include -Wall -O2 -DTEST_SIGTIMEDWAIT
+LDLIBS += -L../../../../lib -lltp 
+
+SRCS    = $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS)) sigtimedwait01
+
+all: $(TARGETS)
+
+sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
+	$(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
+
+install:
+	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
+
+clean:
+	rm -f $(TARGETS)
diff --git a/testcases/kernel/syscalls/sigwait/Makefile b/testcases/kernel/syscalls/sigwait/Makefile
new file mode 100644
index 0000000..2c3a465
--- /dev/null
+++ b/testcases/kernel/syscalls/sigwait/Makefile
@@ -0,0 +1,34 @@
+#
+#  Copyright (c) International Business Machines  Corp., 2009
+#
+#  This program is free software;  you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY;  without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+#  the GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program;  if not, write to the Free Software
+#  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+
+CFLAGS += -I../../../../include -Wall -O2 -DTEST_SIGWAIT
+LDLIBS += -L../../../../lib -lltp 
+
+SRCS    = $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS)) sigwait01
+
+all: $(TARGETS)
+
+sigwait01.o: ../sigwaitinfo/sigwaitinfo01.c
+	$(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
+
+install:
+	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
+
+clean:
+	rm -f $(TARGETS)
diff --git a/testcases/kernel/syscalls/sigwaitinfo/Makefile b/testcases/kernel/syscalls/sigwaitinfo/Makefile
new file mode 100644
index 0000000..299d028
--- /dev/null
+++ b/testcases/kernel/syscalls/sigwaitinfo/Makefile
@@ -0,0 +1,31 @@
+#
+#  Copyright (c) International Business Machines  Corp., 2009
+#
+#  This program is free software;  you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY;  without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+#  the GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program;  if not, write to the Free Software
+#  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+
+CFLAGS += -I../../../../include -Wall -O2 -DTEST_SIGWAITINFO
+LDLIBS += -L../../../../lib -lltp 
+
+SRCS    = $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS))
+
+all: $(TARGETS)
+
+install:
+	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
+
+clean:
+	rm -f $(TARGETS)
diff --git a/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c b/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c
new file mode 100644
index 0000000..ff9ca8f
--- /dev/null
+++ b/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c
@@ -0,0 +1,435 @@
+/*
+ * Copyright (c) Jiri Palecek<jpalecek@web.de>, 2009
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * Further, this software is distributed without any warranty that it is
+ * free of the rightful claim of any third person regarding infringement
+ * or the like.  Any license provided herein, whether implied or
+ * otherwise, applies only to this software file.  Patent licenses, if
+ * any, provided herein do not apply to combinations of this program with
+ * other software, or any other product whatsoever.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ */
+#include "test.h"
+#include "usctest.h"
+#include <errno.h>
+#include <signal.h>
+#include "../utils/include_j_h.h"
+#include "../utils/common_j_h.c"
+#include <limits.h>
+#include "linux_syscall_numbers.h"
+
+#define SUCCEED_OR_DIE(syscall, message, ...)														\
+	(errno = 0,																														\
+		({int ret=syscall(__VA_ARGS__);																			\
+			if(ret==-1)																												\
+				tst_brkm(TBROK|TERRNO, cleanup, message);												\
+			ret;}))
+
+/* Report success iff TEST_RETURN and TEST_ERRNO are equal to
+	 exp_return and exp_errno, resp., and cond is true. If cond is not
+	 true, report condition_errmsg
+*/
+static void report_success_cond(const char *func, const char* file, int line,
+													 long exp_return, int exp_errno, int condition, char* condition_errmsg)
+{
+	if (exp_return == TEST_RETURN && (exp_return != -1 || exp_errno == TEST_ERRNO))
+		if(condition)
+			tst_resm(TPASS, "Test passed");
+		else
+			tst_resm(TFAIL, "%s (%s: %d): %s", func, file, line, condition_errmsg);
+	else if(TEST_RETURN != -1)
+		tst_resm(TFAIL, "%s (%s: %d): Unexpected return value; expected %ld, got %ld",
+						 func, file, line, exp_return, TEST_RETURN);
+	else
+		tst_resm(TFAIL|TTERRNO, "%s (%s: %d): Unexpected failure", func, file, line);
+}
+
+#define REPORT_SUCCESS_COND(exp_return, exp_errno, condition, condition_errmsg)	\
+	report_success_cond(__FUNCTION__, __FILE__, __LINE__, exp_return, exp_errno, condition, condition_errmsg);
+
+/* Report success iff TEST_RETURN and TEST_ERRNO are equal to
+	 exp_return and exp_errno, resp.
+*/
+#define REPORT_SUCCESS(exp_return, exp_errno)					\
+	REPORT_SUCCESS_COND(exp_return, exp_errno, 1, "");
+
+static void cleanup(void) LTP_ATTRIBUTE_NORETURN;
+
+static void empty_handler(int sig)
+{
+}
+
+static void setup(void)
+{
+	tst_sig(FORK, DEF_HANDLER, cleanup);
+	signal(SIGUSR1, empty_handler);
+	signal(SIGALRM, empty_handler);
+	signal(SIGUSR2, SIG_IGN);
+
+	TEST_PAUSE;
+}
+
+static void cleanup(void)
+{
+	TEST_CLEANUP;
+
+	tst_exit();
+}
+
+typedef int (*swi_func)(const sigset_t* set, siginfo_t* info, struct timespec* timeout);
+typedef void (*test_func)(swi_func, int);
+
+static int my_sigwait(const sigset_t* set, siginfo_t* info, struct timespec* timeout)
+{
+	int ret;
+	int err=sigwait(set, &ret);
+
+	if(err == 0)
+		return ret;
+	errno = err;
+	return -1;
+}
+
+static int my_sigwaitinfo(const sigset_t* set, siginfo_t* info, struct timespec* timeout)
+{
+	return sigwaitinfo(set, info);
+}
+
+static int my_sigtimedwait(const sigset_t* set, siginfo_t* info, struct timespec* timeout)
+{
+	return sigtimedwait(set, info, timeout);
+}
+
+static int my_rt_sigtimedwait(const sigset_t* set, siginfo_t* info, struct timespec* timeout)
+{
+	/* The last argument is (number_of_signals)/(bits_per_byte), which are 64 and 8, resp. */
+	return syscall(__NR_rt_sigtimedwait, set, info, timeout, 8);
+}
+
+void test_empty_set(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs;
+	siginfo_t si;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	/* Run a child that will wake us up */
+	child=create_sig_proc(100000, signo, UINT_MAX);
+
+	TEST(sigwaitinfo(&sigs, &si, NULL));
+	REPORT_SUCCESS(-1, EINTR);
+
+	kill(child, SIGTERM);
+}
+
+void test_timeout(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs;
+	siginfo_t si;
+	pid_t child;
+	struct timespec ts = { .tv_sec = 1 };
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+
+	/* Run a child that will wake us up */
+	child=create_sig_proc(100000, signo, UINT_MAX);
+
+	TEST(sigwaitinfo(&sigs, &si, &ts));
+	REPORT_SUCCESS(-1, EAGAIN);
+
+	kill(child, SIGTERM);
+}
+
+/* Note: sigwait-ing for a signal that is not blocked is unspecified
+ * by POSIX; but works for non-ignored signals under Linux
+ */
+void test_unmasked_matching(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs;
+	siginfo_t si;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+
+	/* Run a child that will wake us up */
+	child=create_sig_proc(100000, signo, UINT_MAX);
+
+	TEST(sigwaitinfo(&sigs, &si, NULL));
+	REPORT_SUCCESS_COND(signo, 0, si.si_pid==child && si.si_code==SI_USER && si.si_signo==signo, "Struct siginfo mismatch");
+
+	kill(child, SIGTERM);
+}
+
+void test_unmasked_matching_noinfo(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+	/* Run a child that will wake us up */
+	child=create_sig_proc(100000, signo, UINT_MAX);
+
+	TEST(sigwaitinfo(&sigs, NULL, NULL));
+	REPORT_SUCCESS(signo, 0);
+
+	kill(child, SIGTERM);
+}
+
+void test_masked_matching(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs, oldmask;
+	siginfo_t si;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+	/* let's not get interrupted by our dying child */
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, SIGCHLD);
+
+	SUCCEED_OR_DIE(sigprocmask, "sigprocmask failed", SIG_SETMASK, &sigs, &oldmask);
+
+	/* don't wait on a SIGCHLD */
+	SUCCEED_OR_DIE(sigdelset, "sigaddset failed", &sigs, SIGCHLD);
+
+	/* Run a child that will wake us up */
+	child=create_sig_proc(0, signo, 1);
+
+	TEST(sigwaitinfo(&sigs, &si, NULL));
+	REPORT_SUCCESS_COND(signo, 0, si.si_pid==child && si.si_code==SI_USER && si.si_signo==signo, "Struct siginfo mismatch");
+
+	SUCCEED_OR_DIE(sigprocmask, "restoring original signal mask failed", SIG_SETMASK, &oldmask, &oldmask);
+
+	Tst_count--;
+
+	if(sigismember(&oldmask, signo))
+		tst_resm(TPASS, "sigwaitinfo restored the original mask");
+	else
+		tst_resm(TFAIL, "sigwaitinfo failed to restore the original mask");
+}
+
+void test_masked_matching_rt(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs, oldmask;
+	siginfo_t si;
+	pid_t child[2];
+
+	signo = SIGRTMIN+1;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo+1);
+	/* let's not get interrupted by our dying child */
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, SIGCHLD);
+
+	SUCCEED_OR_DIE(sigprocmask, "sigprocmask failed", SIG_SETMASK, &sigs, &oldmask);
+
+	/* don't wait on a SIGCHLD */
+	SUCCEED_OR_DIE(sigdelset, "sigdelset failed", &sigs, SIGCHLD);
+
+	/* Run a child that will wake us up */
+	child[0]=create_sig_proc(0, signo, 1);
+	child[1]=create_sig_proc(0, signo+1, 1);
+
+	/* Need to be sure both signals arrive at once */
+	sleep(1); /* we could have as well wait()-ed for both children... */
+
+	TEST(sigwaitinfo(&sigs, &si, NULL));
+	REPORT_SUCCESS_COND(signo, 0, si.si_pid==child[0] && si.si_code==SI_USER && si.si_signo==signo, "Struct siginfo mismatch");
+
+	/* eat the other signal */
+	Tst_count--;
+	TEST(sigwaitinfo(&sigs, &si, NULL));
+	REPORT_SUCCESS_COND(signo+1, 0, si.si_pid==child[1] && si.si_code==SI_USER && si.si_signo==signo+1, "Struct siginfo mismatch");
+
+	SUCCEED_OR_DIE(sigprocmask, "restoring original signal mask failed", SIG_SETMASK, &oldmask, &oldmask);
+
+	Tst_count--;
+
+	if(sigismember(&oldmask, signo))
+		tst_resm(TPASS, "sigwaitinfo restored the original mask");
+	else
+		tst_resm(TFAIL, "sigwaitinfo failed to restore the original mask");
+}
+
+void test_masked_matching_noinfo(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs, oldmask;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+	/* let's not get interrupted by our dying child */
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, SIGCHLD);
+
+	SUCCEED_OR_DIE(sigprocmask, "sigprocmask failed", SIG_SETMASK, &sigs, &oldmask);
+
+	/* don't wait on a SIGCHLD */
+	SUCCEED_OR_DIE(sigdelset, "sigaddset failed", &sigs, SIGCHLD);
+
+	/* Run a child that will wake us up */
+	child=create_sig_proc(0, signo, 1);
+
+	TEST(sigwaitinfo(&sigs, NULL, NULL));
+	REPORT_SUCCESS(signo, 0);
+
+	SUCCEED_OR_DIE(sigprocmask, "restoring original signal mask failed", SIG_SETMASK, &oldmask, &oldmask);
+
+	Tst_count--;
+
+	if(sigismember(&oldmask, signo))
+		tst_resm(TPASS, "sigwaitinfo restored the original mask");
+	else
+		tst_resm(TFAIL, "sigwaitinfo failed to restore the original mask");
+
+}
+
+void test_bad_address(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs, oldmask;
+	pid_t child;
+
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, signo);
+	/* let's not get interrupted by our dying child */
+	SUCCEED_OR_DIE(sigaddset, "sigaddset failed", &sigs, SIGCHLD);
+
+	SUCCEED_OR_DIE(sigprocmask, "sigprocmask failed", SIG_SETMASK, &sigs, &oldmask);
+
+	/* don't wait on a SIGCHLD */
+	SUCCEED_OR_DIE(sigdelset, "sigaddset failed", &sigs, SIGCHLD);
+
+	/* Run a child that will wake us up */
+	child=create_sig_proc(0, signo, 1);
+
+	TEST(sigwaitinfo(&sigs, (void*)1, NULL));
+	REPORT_SUCCESS(-1, EFAULT);
+
+	SUCCEED_OR_DIE(sigprocmask, "sigprocmask failed", SIG_SETMASK, &oldmask, &oldmask);
+
+	kill(child, SIGTERM);
+}
+
+void test_bad_address2(swi_func sigwaitinfo, int signo)
+{
+	TEST(sigwaitinfo((void*)1, NULL, NULL));
+	REPORT_SUCCESS(-1, EFAULT);
+}
+
+void test_bad_address3(swi_func sigwaitinfo, int signo)
+{
+	sigset_t sigs;
+	SUCCEED_OR_DIE(sigemptyset, "sigemptyset failed", &sigs);
+
+	TEST(sigwaitinfo(&sigs, NULL, (void*)1));
+	REPORT_SUCCESS(-1, EFAULT);
+}
+
+struct test_desc {
+	test_func tf;
+	swi_func swi;
+	int signo;
+} tests[]={
+#if defined TEST_RT_SIGTIMEDWAIT
+	test_empty_set, my_rt_sigtimedwait, SIGUSR1,
+	test_unmasked_matching, my_rt_sigtimedwait, SIGUSR1,
+	test_masked_matching, my_rt_sigtimedwait, SIGUSR1,
+	test_unmasked_matching_noinfo, my_rt_sigtimedwait, SIGUSR1,
+	test_masked_matching_noinfo, my_rt_sigtimedwait, SIGUSR1,
+	test_bad_address, my_rt_sigtimedwait, SIGUSR1,
+	test_bad_address2, my_rt_sigtimedwait, SIGUSR1,
+	test_bad_address3, my_rt_sigtimedwait, SIGUSR1,
+	test_timeout, my_rt_sigtimedwait, 0,
+
+	/* Special cases */
+	/* 1: sigwaitinfo does respond to ignored signal */
+	test_masked_matching, my_rt_sigtimedwait, SIGUSR2,
+
+	/* 2: An ignored signal doesn't cause sigwaitinfo to return EINTR */
+	test_timeout, my_rt_sigtimedwait, SIGUSR2,
+
+	/* 3: The handler is not called when the signal is waited for by sigwaitinfo */
+	test_masked_matching, my_rt_sigtimedwait, SIGTERM,
+
+	/* 4: Simultaneous realtime signals are delivered in the order of increasing signal number */
+	test_masked_matching_rt, my_rt_sigtimedwait, -1,
+#endif
+#if defined TEST_SIGWAIT
+	test_unmasked_matching_noinfo, my_sigwait, SIGUSR1,
+	test_masked_matching_noinfo, my_sigwait, SIGUSR1,
+#endif
+#if defined TEST_SIGWAITINFO
+	test_empty_set, my_sigwaitinfo, SIGUSR1,
+	test_unmasked_matching, my_sigwaitinfo, SIGUSR1,
+	test_masked_matching, my_sigwaitinfo, SIGUSR1,
+	test_unmasked_matching_noinfo, my_sigwaitinfo, SIGUSR1,
+	test_masked_matching_noinfo, my_sigwaitinfo, SIGUSR1,
+	test_bad_address, my_sigwaitinfo, SIGUSR1,
+	test_bad_address2, my_sigwaitinfo, SIGUSR1,
+#endif
+#if defined TEST_SIGTIMEDWAIT
+	test_empty_set, my_sigtimedwait, SIGUSR1,
+	test_unmasked_matching, my_sigtimedwait, SIGUSR1,
+	test_masked_matching, my_sigtimedwait, SIGUSR1,
+	test_unmasked_matching_noinfo, my_sigtimedwait, SIGUSR1,
+	test_masked_matching_noinfo, my_sigtimedwait, SIGUSR1,
+	test_bad_address, my_sigtimedwait, SIGUSR1,
+	test_bad_address2, my_sigtimedwait, SIGUSR1,
+	test_bad_address3, my_sigtimedwait, SIGUSR1,
+	test_timeout, my_sigtimedwait, 0,
+#endif
+};
+
+#if defined TEST_SIGWAITINFO
+const char* TCID="sigwaitinfo01";
+#elif defined TEST_RT_SIGTIMEDWAIT
+const char* TCID="rt_sigtimedwait01";
+#elif defined TEST_SIGTIMEDWAIT
+const char* TCID="sigtimedwait01";
+#elif defined TEST_SIGWAIT
+const char* TCID="sigwait01";
+#endif
+
+extern int Tst_count;
+
+int TST_TOTAL = sizeof(tests)/sizeof(*tests);
+
+int main(int argc, char** argv)
+{
+	unsigned i;
+	int lc;
+	char* msg;
+
+	/* parse standard options */
+	if ((msg = parse_opts(argc, argv, (option_t *) NULL, NULL)) !=
+			(char *)NULL) {
+		tst_brkm(TBROK, cleanup, "OPTION PARSING ERROR - %s", msg);
+		/*NOT REACHED */
+	}
+
+	setup();
+
+	for(lc = 0; TEST_LOOPING(lc); ++lc) {
+		Tst_count = 0;
+
+		for(i=0; i<sizeof(tests)/sizeof(*tests); i++) {
+			alarm(10); /* arrange a 10 second timeout */
+			tests[i].tf(tests[i].swi, tests[i].signo);
+		}
+		alarm(0);
+	}
+
+	cleanup();
+}

[-- Attachment #3: Type: text/plain, Size: 399 bytes --]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Garrett Cooper]

2009/10/25 Jiří Paleček <jpalecek@web.de>:
> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
> <subrata@linux.vnet.ibm.com> wrote:
>
>> Jiri,
>>
>> Any further thoughts on this ?
>
> Yes, see the attachment.
>
> I created the directories for the different tests (rt_sigtimedwait,
> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the same
> source. Please, tell me if that is OK.
>
> Regards
>    Jiri Palecek
>>
>> On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote:
>>>
>>> Hey Jiri,
>>>
>>> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote:
>>> > Hello,
>>> >
>>> > I've decided to create a test for the rt_sigwaitinfo syscall. There are
>>> > other functions with similar interface (defined by POSIX) in libc -
>>> > particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo
>>>
>>> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
>>>
>>> > test could easily tests these too, so I wonder whether we want to test
>>> > these too, and if yes, whether these tests can be located in the same
>>> > executable.
>>>
>>> If you already have the logic to write the above tests, then please
>>> create separate tests for sigwait, sigtimedwait and sigwaitinfo
>>> (separate directories as well), and separate for rt_sigwaitinfo syscall.
>>>
>>> Regards--
>>> Subrata

    The Makefiles need to be rewritten because a) they don't use the
new infrastructure, and b) they break requirements for
out-of-build-tree support. Please read README.mk-devel and ping me
with any questions you may have.
Thanks,
-Garrett

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Subrata Modak]

On Sun, 2009-10-25 at 20:49 -0700, Garrett Cooper wrote: 
> 2009/10/25 Jiří Paleček <jpalecek@web.de>:
> > On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
> > <subrata@linux.vnet.ibm.com> wrote:
> >
> >> Jiri,
> >>
> >> Any further thoughts on this ?
> >
> > Yes, see the attachment.
> >
> > I created the directories for the different tests (rt_sigtimedwait,
> > sigwaitinfo etc.), but to avoid copy-pasting the code, they share the same
> > source. Please, tell me if that is OK.
> >
> > Regards
> >    Jiri Palecek
> >>
> >> On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote:
> >>>
> >>> Hey Jiri,
> >>>
> >>> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote:
> >>> > Hello,
> >>> >
> >>> > I've decided to create a test for the rt_sigwaitinfo syscall. There are
> >>> > other functions with similar interface (defined by POSIX) in libc -
> >>> > particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo
> >>>
> >>> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
> >>>
> >>> > test could easily tests these too, so I wonder whether we want to test
> >>> > these too, and if yes, whether these tests can be located in the same
> >>> > executable.
> >>>
> >>> If you already have the logic to write the above tests, then please
> >>> create separate tests for sigwait, sigtimedwait and sigwaitinfo
> >>> (separate directories as well), and separate for rt_sigwaitinfo syscall.
> >>>
> >>> Regards--
> >>> Subrata
> 
>     The Makefiles need to be rewritten because a) they don't use the
> new infrastructure, and b) they break requirements for
> out-of-build-tree support. Please read README.mk-devel and ping me

As Garret says. He has done huge hard work on the Makefile.

Regards--
Subrata

> with any questions you may have.
> Thanks,
> -Garrett


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Jiří Paleček]

On Mon, 26 Oct 2009 04:49:57 +0100, Garrett Cooper <yanegomi@gmail.com>  
wrote:

> 2009/10/25 Jiří Paleček <jpalecek@web.de>:
>> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
>> <subrata@linux.vnet.ibm.com> wrote:
>>
>>> Jiri,
>>>
>>> Any further thoughts on this ?
>>
>> Yes, see the attachment.
>>
>> I created the directories for the different tests (rt_sigtimedwait,
>> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the  
>> same
>> source. Please, tell me if that is OK.
>>
>> Regards
>>    Jiri Palecek
>>>
>>> On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote:
>>>>
>>>> Hey Jiri,
>>>>
>>>> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote:
>>>> > Hello,
>>>> >
>>>> > I've decided to create a test for the rt_sigwaitinfo syscall. There  
>>>> are
>>>> > other functions with similar interface (defined by POSIX) in libc -
>>>> > particularly sigwait, sigtimedwait and sigwaitinfo. The  
>>>> rt_sigwaitinfo
>>>>
>>>> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
>>>>
>>>> > test could easily tests these too, so I wonder whether we want to  
>>>> test
>>>> > these too, and if yes, whether these tests can be located in the  
>>>> same
>>>> > executable.
>>>>
>>>> If you already have the logic to write the above tests, then please
>>>> create separate tests for sigwait, sigtimedwait and sigwaitinfo
>>>> (separate directories as well), and separate for rt_sigwaitinfo  
>>>> syscall.
>>>>
>>>> Regards--
>>>> Subrata
>
>     The Makefiles need to be rewritten because a) they don't use the
> new infrastructure, and b) they break requirements for
> out-of-build-tree support. Please read README.mk-devel and ping me
> with any questions you may have.

I read the document, but I'm not sure I understand it. What are the actual  
requirements on makefile rules that are needed? I looked at the  
commands/unzip makefile, and I can't see where does $(ZIPFILE) come from,  
and how does it and $(DIR) address out-of-tree build.

I think I'm gonna refactor the code so I don't need that special make rule.

Regards
     Jiri Palcek

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Garrett Cooper]

2009/10/25 Jiří Paleček <jpalecek@web.de>:
> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
> <subrata@linux.vnet.ibm.com> wrote:
>
>> Jiri,
>>
>> Any further thoughts on this ?
>
> Yes, see the attachment.
>
> I created the directories for the different tests (rt_sigtimedwait,
> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the same
> source. Please, tell me if that is OK.

I'm a bit confused by let me help analyze the Makefile and provide critiques:

The basic template for any Makefile now, is as follows:

# LICENSING TORT, e.g. GPLv2 License, etc.

# <TOP-SRCDIR DEFINITION>

# <PRE-INCLUDE>

# <ADDITIONAL MAKE LOGIC GOES HERE>

# <POST-INCLUDE>

The description of these components is as follows:

===========================================================
TOP-SRCDIR DEFINITION
===========================================================
top_srcdir ?= <relative path from current Makefile to the top of the
source tree>

Example 1 (say, from testcases/realtime):

top_srcdir ?= ../..

Example 2 (say, from lib):

top_srcdir ?= ..

The ?= is important, because this value can be redefined at ANY time
-- I've been considering making this assignment operator := though,
because it should be set just once per Makefile, and isn't being
exported anymore (it was a design mistake I made in the beginning that
Mike F. corrected me because I wasn't adhering to correct autotools
variable conventions).

===========================================================
PRE-INCLUDE
===========================================================
This is important, and may lead to potential confusion.

env_pre.mk is used for most includes outside of the testcases portion
of the tree. This has a minimal set of assumptions and dependent
targets, because it's designed to work with doc, lib, tools, and
utils. This can also be used in `trunk' situations (discussed below)
where no C-files need to be compiled, and/or linked in with libltp.a.
This also adds $(abs_top_srcdir)/include to the CPPFLAGS so you don't
need to add this to 300+ Makefiles (like it was before :)...].

testcases.mk is used for rest of the cases under testcases. It does
the following for you:
1. Everything in env_pre.mk.
2. Adds dependencies for libltp.a.
3. Adds -lltp to LDLIBS.
4. Adds dependencies for testcases/kernel/include/syscall_numbers.h
5. Adds an optional hook for the tst_res apps in tools/apicmds so you
can run your tests out of the local directory before install [assuming
they're coded properly :)...].

All of the additional steps are done for developer convenience, so
that running make install from testcases/kernel/syscalls/open doesn't
require that I manually go into lib/ and testcases/kernel/include
beforehand and run a make all, and have to duplicate a lot of
unnecessary logic in the Makefiles.

===========================================================
ADDITIONAL MAKE LOGIC GOES HERE
===========================================================

Whatever you want to put in here that isn't provided with the defaults
in env_post.mk, generic_leaf_target.inc, or generic_trunk_target.inc,
so feel free to `use your imagination' as to whatever you may put in
here, but the only cases that you should have to deal with are:

1. Multiple C files / objects -> one or more executables.
2. Items without implicit rule mappings, e.g. .c -> .o.

===========================================================
POST-INCLUDE:
===========================================================

- For all directory traversing Makefiles you include the `trunk
target' Makefile:

include $(top_srcdir)/include/mk/generic_trunk_target.mk

- For all non-directory traversing Makefiles, you include the `leaf
target' Makefile.

include $(top_srcdir)/include/mk/generic_leaf_target.mk

===========================================================

Now, to critique your proposed Makefiles...

testcases/kernel/syscalls/rt_sigtimedwait/Makefile:

+CFLAGS += -I../../../../include -Wall -O2 -DTEST_RT_SIGTIMEDWAIT
+LDLIBS += -L../../../../lib -lltp
+
+SRCS    = $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS)) rt_sigtimedwait01
+
+all: $(TARGETS)
+
+rt_sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
+	$(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
+
+install:
+	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
+
+clean:
+	rm -f $(TARGETS)

Given the above explanation, I would write this like the following
(minus the licensing tort, and with improper indented vars -- bloody
GMail :(...):

=============================================
top_srcdir ?= ../../../..

include $(top_srcdir)/include/mk/testcases.mk

# NOTE: Placement doesn't matter, but for readability and consistency
it should go here.
CPPFLAGS += -DTEST_RT_SIGTIMEDWAIT

# NOTE: Placement for this Make target doesn't matter... just so long
as it's defined in the Makefile.
rt_sigtimedwait01: $(abs_srcdir)/../sigwaitinfo/sigwaitinfo01.c
	$(COMPILE.o) $(OUTPUT_OPTION) $^

# NOTE: Don't modify MAKE_TARGETS here because it isn't set yet, and
the default is to pick up all existing C files in the
# current directory and make them into single-source executables, e.g.
# sigwaitinfo01.c -> sigwaitinfo01.o -> sigwaitinfo01 ;)...

include $(top_srcdir)/include/mk/generic_leaf_target.mk

MAKE_TARGETS += rt_sigtimedwait01
=============================================

Similar logic would be applied to your other Makefile, minus the
CPPFLAGS assignment.

Please note that your binary is no longer linked into
$(abs_top_builddir)/testcases/bin -- it's instead install(1)'ed
directly into $(DESTDIR)/$(prefix)/testcases/bin . This was done to
facilitate proper installation by using the correct mode, and also to
avoid broken/hacky symlinking operations.

Hope that helps describe things a bit better... let me know if I
should add this to a README or something...

Cheers!
-Garrett

>> On Tue, 2009-10-13 at 17:43 +0530, Subrata Modak wrote:
>>>
>>> Hey Jiri,
>>>
>>> On Tue, 2009-09-29 at 16:28 +0200, Jiří Paleček wrote:
>>> > Hello,
>>> >
>>> > I've decided to create a test for the rt_sigwaitinfo syscall. There are
>>> > other functions with similar interface (defined by POSIX) in libc -
>>> > particularly sigwait, sigtimedwait and sigwaitinfo. The rt_sigwaitinfo
>>>
>>> The sigwait, sigtimedwait and sigwaitinfo testcases are not in LTP.
>>>
>>> > test could easily tests these too, so I wonder whether we want to test
>>> > these too, and if yes, whether these tests can be located in the same
>>> > executable.
>>>
>>> If you already have the logic to write the above tests, then please
>>> create separate tests for sigwait, sigtimedwait and sigwaitinfo
>>> (separate directories as well), and separate for rt_sigwaitinfo syscall.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Jiří Paleček]

Hello,


yaneurabeya wrote:
> 
> 2009/10/25 Jiří Paleček <jpalecek@web.de>:
>> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
>> <subrata@linux.vnet.ibm.com> wrote:
>>
>>> Jiri,
>>>
>>> Any further thoughts on this ?
>>
>> Yes, see the attachment.
>>
>> I created the directories for the different tests (rt_sigtimedwait,
>> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the
>> same
>> source. Please, tell me if that is OK.
> 
> I'm a bit confused by let me help analyze the Makefile and provide
> critiques:
> 
> The basic template for any Makefile now, is as follows:
> 
> # LICENSING TORT, e.g. GPLv2 License, etc.
> 
> # <TOP-SRCDIR DEFINITION>
> 
> # <PRE-INCLUDE>
> 
> # <ADDITIONAL MAKE LOGIC GOES HERE>
> 
> # <POST-INCLUDE>
> 
> The description of these components is as follows:
> 
> ===========================================================
> TOP-SRCDIR DEFINITION
> ===========================================================
> top_srcdir ?= <relative path from current Makefile to the top of the
> source tree>
> 
> Example 1 (say, from testcases/realtime):
> 
> top_srcdir ?= ../..
> 
> Example 2 (say, from lib):
> 
> top_srcdir ?= ..
> 
> The ?= is important, because this value can be redefined at ANY time
> -- I've been considering making this assignment operator := though,
> because it should be set just once per Makefile, and isn't being
> exported anymore (it was a design mistake I made in the beginning that
> Mike F. corrected me because I wasn't adhering to correct autotools
> variable conventions).
> 
> ===========================================================
> PRE-INCLUDE
> ===========================================================
> This is important, and may lead to potential confusion.
> 
> env_pre.mk is used for most includes outside of the testcases portion
> of the tree. This has a minimal set of assumptions and dependent
> targets, because it's designed to work with doc, lib, tools, and
> utils. This can also be used in `trunk' situations (discussed below)
> where no C-files need to be compiled, and/or linked in with libltp.a.
> This also adds $(abs_top_srcdir)/include to the CPPFLAGS so you don't
> need to add this to 300+ Makefiles (like it was before :)...].
> 
> testcases.mk is used for rest of the cases under testcases. It does
> the following for you:
> 1. Everything in env_pre.mk.
> 2. Adds dependencies for libltp.a.
> 3. Adds -lltp to LDLIBS.
> 4. Adds dependencies for testcases/kernel/include/syscall_numbers.h
> 5. Adds an optional hook for the tst_res apps in tools/apicmds so you
> can run your tests out of the local directory before install [assuming
> they're coded properly :)...].
> 
> All of the additional steps are done for developer convenience, so
> that running make install from testcases/kernel/syscalls/open doesn't
> require that I manually go into lib/ and testcases/kernel/include
> beforehand and run a make all, and have to duplicate a lot of
> unnecessary logic in the Makefiles.
> 
> ===========================================================
> ADDITIONAL MAKE LOGIC GOES HERE
> ===========================================================
> 
> Whatever you want to put in here that isn't provided with the defaults
> in env_post.mk, generic_leaf_target.inc, or generic_trunk_target.inc,
> so feel free to `use your imagination' as to whatever you may put in
> here, but the only cases that you should have to deal with are:
> 
> 1. Multiple C files / objects -> one or more executables.
> 2. Items without implicit rule mappings, e.g. .c -> .o.
> 
> ===========================================================
> POST-INCLUDE:
> ===========================================================
> 
> - For all directory traversing Makefiles you include the `trunk
> target' Makefile:
> 
> include $(top_srcdir)/include/mk/generic_trunk_target.mk
> 
> - For all non-directory traversing Makefiles, you include the `leaf
> target' Makefile.
> 
> include $(top_srcdir)/include/mk/generic_leaf_target.mk
> 
> ===========================================================
> 
> Now, to critique your proposed Makefiles...
> 
> testcases/kernel/syscalls/rt_sigtimedwait/Makefile:
> 
> +CFLAGS += -I../../../../include -Wall -O2 -DTEST_RT_SIGTIMEDWAIT
> +LDLIBS += -L../../../../lib -lltp
> +
> +SRCS    = $(wildcard *.c)
> +TARGETS = $(patsubst %.c,%,$(SRCS)) rt_sigtimedwait01
> +
> +all: $(TARGETS)
> +
> +rt_sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
> +	$(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
> +
> +install:
> +	@set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
> +
> +clean:
> +	rm -f $(TARGETS)
> 
> Given the above explanation, I would write this like the following
> (minus the licensing tort, and with improper indented vars -- bloody
> GMail :(...):
> 
> =============================================
> top_srcdir ?= ../../../..
> 
> include $(top_srcdir)/include/mk/testcases.mk
> 
> # NOTE: Placement doesn't matter, but for readability and consistency
> it should go here.
> CPPFLAGS += -DTEST_RT_SIGTIMEDWAIT
> 
> # NOTE: Placement for this Make target doesn't matter... just so long
> as it's defined in the Makefile.
> rt_sigtimedwait01: $(abs_srcdir)/../sigwaitinfo/sigwaitinfo01.c
> 	$(COMPILE.o) $(OUTPUT_OPTION) $^
> 
> # NOTE: Don't modify MAKE_TARGETS here because it isn't set yet, and
> the default is to pick up all existing C files in the
> # current directory and make them into single-source executables, e.g.
> # sigwaitinfo01.c -> sigwaitinfo01.o -> sigwaitinfo01 ;)...
> 
> include $(top_srcdir)/include/mk/generic_leaf_target.mk
> 
> MAKE_TARGETS += rt_sigtimedwait01
> =============================================
> 
> Similar logic would be applied to your other Makefile, minus the
> CPPFLAGS assignment.
> 
> Please note that your binary is no longer linked into
> $(abs_top_builddir)/testcases/bin -- it's instead install(1)'ed
> directly into $(DESTDIR)/$(prefix)/testcases/bin . This was done to
> facilitate proper installation by using the correct mode, and also to
> avoid broken/hacky symlinking operations.
> 
> Hope that helps describe things a bit better... let me know if I
> should add this to a README or something...
> 
> 

Thank you, it is definitely clearer now. I think it should be mentioned in
the README, including some list of the ltp makefile variables (like
$(abs_srcdir)). I'll wait with a new patch for the new build system to
appear in a release, though.

What I still don't get is where does the ZIPFILE variable get its value
(this was the first place where I sought inspiration):

jirka@debian:/usr/src/ltp-cvs$ fgrep -RI * -e ZIPFILE
testcases/commands/unzip/Makefile:$(INSTALL_TARGETS): $(ZIPFILE)
testcases/commands/unzip/Makefile:$(ZIPFILE): $(DIR)
jirka@debian:/usr/src/ltp-cvs$

Regards
    Jiri Palecek

-- 
View this message in context: http://old.nabble.com/New-test--tp25664200p26128108.html
Sent from the ltp-list mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Garrett Cooper]

On Fri, Oct 30, 2009 at 3:56 AM, Jiří Paleček <jpalecek@web.de> wrote:
>
> Hello,
>
>
> yaneurabeya wrote:
>>
>> 2009/10/25 Jiří Paleček <jpalecek@web.de>:
>>> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
>>> <subrata@linux.vnet.ibm.com> wrote:
>>>
>>>> Jiri,
>>>>
>>>> Any further thoughts on this ?
>>>
>>> Yes, see the attachment.
>>>
>>> I created the directories for the different tests (rt_sigtimedwait,
>>> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the
>>> same
>>> source. Please, tell me if that is OK.
>>
>> I'm a bit confused by let me help analyze the Makefile and provide
>> critiques:
>>
>> The basic template for any Makefile now, is as follows:
>>
>> # LICENSING TORT, e.g. GPLv2 License, etc.
>>
>> # <TOP-SRCDIR DEFINITION>
>>
>> # <PRE-INCLUDE>
>>
>> # <ADDITIONAL MAKE LOGIC GOES HERE>
>>
>> # <POST-INCLUDE>
>>
>> The description of these components is as follows:
>>
>> ===========================================================
>> TOP-SRCDIR DEFINITION
>> ===========================================================
>> top_srcdir ?= <relative path from current Makefile to the top of the
>> source tree>
>>
>> Example 1 (say, from testcases/realtime):
>>
>> top_srcdir ?= ../..
>>
>> Example 2 (say, from lib):
>>
>> top_srcdir ?= ..
>>
>> The ?= is important, because this value can be redefined at ANY time
>> -- I've been considering making this assignment operator := though,
>> because it should be set just once per Makefile, and isn't being
>> exported anymore (it was a design mistake I made in the beginning that
>> Mike F. corrected me because I wasn't adhering to correct autotools
>> variable conventions).
>>
>> ===========================================================
>> PRE-INCLUDE
>> ===========================================================
>> This is important, and may lead to potential confusion.
>>
>> env_pre.mk is used for most includes outside of the testcases portion
>> of the tree. This has a minimal set of assumptions and dependent
>> targets, because it's designed to work with doc, lib, tools, and
>> utils. This can also be used in `trunk' situations (discussed below)
>> where no C-files need to be compiled, and/or linked in with libltp.a.
>> This also adds $(abs_top_srcdir)/include to the CPPFLAGS so you don't
>> need to add this to 300+ Makefiles (like it was before :)...].
>>
>> testcases.mk is used for rest of the cases under testcases. It does
>> the following for you:
>> 1. Everything in env_pre.mk.
>> 2. Adds dependencies for libltp.a.
>> 3. Adds -lltp to LDLIBS.
>> 4. Adds dependencies for testcases/kernel/include/syscall_numbers.h
>> 5. Adds an optional hook for the tst_res apps in tools/apicmds so you
>> can run your tests out of the local directory before install [assuming
>> they're coded properly :)...].
>>
>> All of the additional steps are done for developer convenience, so
>> that running make install from testcases/kernel/syscalls/open doesn't
>> require that I manually go into lib/ and testcases/kernel/include
>> beforehand and run a make all, and have to duplicate a lot of
>> unnecessary logic in the Makefiles.
>>
>> ===========================================================
>> ADDITIONAL MAKE LOGIC GOES HERE
>> ===========================================================
>>
>> Whatever you want to put in here that isn't provided with the defaults
>> in env_post.mk, generic_leaf_target.inc, or generic_trunk_target.inc,
>> so feel free to `use your imagination' as to whatever you may put in
>> here, but the only cases that you should have to deal with are:
>>
>> 1. Multiple C files / objects -> one or more executables.
>> 2. Items without implicit rule mappings, e.g. .c -> .o.
>>
>> ===========================================================
>> POST-INCLUDE:
>> ===========================================================
>>
>> - For all directory traversing Makefiles you include the `trunk
>> target' Makefile:
>>
>> include $(top_srcdir)/include/mk/generic_trunk_target.mk
>>
>> - For all non-directory traversing Makefiles, you include the `leaf
>> target' Makefile.
>>
>> include $(top_srcdir)/include/mk/generic_leaf_target.mk
>>
>> ===========================================================
>>
>> Now, to critique your proposed Makefiles...
>>
>> testcases/kernel/syscalls/rt_sigtimedwait/Makefile:
>>
>> +CFLAGS += -I../../../../include -Wall -O2 -DTEST_RT_SIGTIMEDWAIT
>> +LDLIBS += -L../../../../lib -lltp
>> +
>> +SRCS    = $(wildcard *.c)
>> +TARGETS = $(patsubst %.c,%,$(SRCS)) rt_sigtimedwait01
>> +
>> +all: $(TARGETS)
>> +
>> +rt_sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
>> +     $(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
>> +
>> +install:
>> +     @set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
>> +
>> +clean:
>> +     rm -f $(TARGETS)
>>
>> Given the above explanation, I would write this like the following
>> (minus the licensing tort, and with improper indented vars -- bloody
>> GMail :(...):
>>
>> =============================================
>> top_srcdir ?= ../../../..
>>
>> include $(top_srcdir)/include/mk/testcases.mk
>>
>> # NOTE: Placement doesn't matter, but for readability and consistency
>> it should go here.
>> CPPFLAGS += -DTEST_RT_SIGTIMEDWAIT
>>
>> # NOTE: Placement for this Make target doesn't matter... just so long
>> as it's defined in the Makefile.
>> rt_sigtimedwait01: $(abs_srcdir)/../sigwaitinfo/sigwaitinfo01.c
>>       $(COMPILE.o) $(OUTPUT_OPTION) $^
>>
>> # NOTE: Don't modify MAKE_TARGETS here because it isn't set yet, and
>> the default is to pick up all existing C files in the
>> # current directory and make them into single-source executables, e.g.
>> # sigwaitinfo01.c -> sigwaitinfo01.o -> sigwaitinfo01 ;)...
>>
>> include $(top_srcdir)/include/mk/generic_leaf_target.mk
>>
>> MAKE_TARGETS += rt_sigtimedwait01
>> =============================================
>>
>> Similar logic would be applied to your other Makefile, minus the
>> CPPFLAGS assignment.
>>
>> Please note that your binary is no longer linked into
>> $(abs_top_builddir)/testcases/bin -- it's instead install(1)'ed
>> directly into $(DESTDIR)/$(prefix)/testcases/bin . This was done to
>> facilitate proper installation by using the correct mode, and also to
>> avoid broken/hacky symlinking operations.
>>
>> Hope that helps describe things a bit better... let me know if I
>> should add this to a README or something...
>>
>>
>
> Thank you, it is definitely clearer now. I think it should be mentioned in
> the README, including some list of the ltp makefile variables (like
> $(abs_srcdir)). I'll wait with a new patch for the new build system to
> appear in a release, though.
>
> What I still don't get is where does the ZIPFILE variable get its value
> (this was the first place where I sought inspiration):
>
> jirka@debian:/usr/src/ltp-cvs$ fgrep -RI * -e ZIPFILE
> testcases/commands/unzip/Makefile:$(INSTALL_TARGETS): $(ZIPFILE)
> testcases/commands/unzip/Makefile:$(ZIPFILE): $(DIR)
> jirka@debian:/usr/src/ltp-cvs$

Ok, I'll add this information as an additional reference to README.mk-devel.

ZIPFILE is most likely an ad-hoc variable defined in that Makefile
that needs to be added to the new Makefile (it's missing from install
and it's something that I forgot to add to TODO even though I noticed
it once or twice -- I need to note all of the issues clearly this
weekend after I go over the logs manually to ensure that I didn't miss
anything by accident). Assuming that ZIPFILE's generated at build time
(which it should be) you're fine getting away with ZIPFILE being a
`bareword' value relative to the current directory. The only possible
issue is that you'll have to ensure that the destination directory
exists in order for out-of-build-tree support to continue to function
properly (I don't expect people to get this correct all of the time,
but I'd like to keep breakage down to a minimum because it impacts
folks who cross-compile for multiple targets using the same src
directory like my group). You can do this similar to the following:

foo:
    mkdir -p $@
foo/bar: foo
    # fake tab; do something to create foo/bar

If foo/bar isn't a variable, then it can be expressed as:

foo:
    mkdir -p $@
foo/bar: $$(@D)
    # fake tab; do something to create foo/bar

Specifying the directory as a dependency of the target has the two
following benefits:
1. Ensures that the dependency remains constant and the requirement is
ensured from make (this is key).
2. Speeds up the build because adding comparable logic to each build
and install rule (test -d foo || mkdir -p foo) I've discovered is
considerably slower than being dependent on the directory and having
make fill in the blanks as necessary. The difference was on the order
of at least 1~2 mins from what I saw on the Cisco build servers I use
and my personal machine.

The dependency targets (e.g. foo) should be automatically available
via some default logic called up in .../include/mk/env_post.mk using
generate_install_rule_dir_dep .../include/mk/functions.mk, but I've
run into some corner cases where this isn't correct (some of the
INSTALL_TARGETS specified in Makefile.inc, IIRC), so I'll need to fix
something minor after I stare at the problem from a different angle
(it's most likely something really simple that I overlooked by
accident).

I've made some bad assumptions too that I've had to fix after testing
in out-of-build-tree, so testing this new functionality is more
complicated than traditional in-build-tree support, but if I can get a
build-bot up and going for LTP which uses out-of-build-tree, this
would be easy to automate longterm. I don't forsee completing this
before the end of November though.

So -- in summary: relative paths from current directory are ok -- just
be sure that the directory is a dependency of the target and is
created before the target is created or functional issues will occur
(best case consistent build errors -- worst case race conditions in
the source tree :[...).

Cheers,
-Garrett

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New test?

[Garrett Cooper]

On Fri, Oct 30, 2009 at 4:21 AM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Fri, Oct 30, 2009 at 3:56 AM, Jiří Paleček <jpalecek@web.de> wrote:
>>
>> Hello,
>>
>>
>> yaneurabeya wrote:
>>>
>>> 2009/10/25 Jiří Paleček <jpalecek@web.de>:
>>>> On Sun, 18 Oct 2009 20:22:00 +0200, Subrata Modak
>>>> <subrata@linux.vnet.ibm.com> wrote:
>>>>
>>>>> Jiri,
>>>>>
>>>>> Any further thoughts on this ?
>>>>
>>>> Yes, see the attachment.
>>>>
>>>> I created the directories for the different tests (rt_sigtimedwait,
>>>> sigwaitinfo etc.), but to avoid copy-pasting the code, they share the
>>>> same
>>>> source. Please, tell me if that is OK.
>>>
>>> I'm a bit confused by let me help analyze the Makefile and provide
>>> critiques:
>>>
>>> The basic template for any Makefile now, is as follows:
>>>
>>> # LICENSING TORT, e.g. GPLv2 License, etc.
>>>
>>> # <TOP-SRCDIR DEFINITION>
>>>
>>> # <PRE-INCLUDE>
>>>
>>> # <ADDITIONAL MAKE LOGIC GOES HERE>
>>>
>>> # <POST-INCLUDE>
>>>
>>> The description of these components is as follows:
>>>
>>> ===========================================================
>>> TOP-SRCDIR DEFINITION
>>> ===========================================================
>>> top_srcdir ?= <relative path from current Makefile to the top of the
>>> source tree>
>>>
>>> Example 1 (say, from testcases/realtime):
>>>
>>> top_srcdir ?= ../..
>>>
>>> Example 2 (say, from lib):
>>>
>>> top_srcdir ?= ..
>>>
>>> The ?= is important, because this value can be redefined at ANY time
>>> -- I've been considering making this assignment operator := though,
>>> because it should be set just once per Makefile, and isn't being
>>> exported anymore (it was a design mistake I made in the beginning that
>>> Mike F. corrected me because I wasn't adhering to correct autotools
>>> variable conventions).
>>>
>>> ===========================================================
>>> PRE-INCLUDE
>>> ===========================================================
>>> This is important, and may lead to potential confusion.
>>>
>>> env_pre.mk is used for most includes outside of the testcases portion
>>> of the tree. This has a minimal set of assumptions and dependent
>>> targets, because it's designed to work with doc, lib, tools, and
>>> utils. This can also be used in `trunk' situations (discussed below)
>>> where no C-files need to be compiled, and/or linked in with libltp.a.
>>> This also adds $(abs_top_srcdir)/include to the CPPFLAGS so you don't
>>> need to add this to 300+ Makefiles (like it was before :)...].
>>>
>>> testcases.mk is used for rest of the cases under testcases. It does
>>> the following for you:
>>> 1. Everything in env_pre.mk.
>>> 2. Adds dependencies for libltp.a.
>>> 3. Adds -lltp to LDLIBS.
>>> 4. Adds dependencies for testcases/kernel/include/syscall_numbers.h
>>> 5. Adds an optional hook for the tst_res apps in tools/apicmds so you
>>> can run your tests out of the local directory before install [assuming
>>> they're coded properly :)...].
>>>
>>> All of the additional steps are done for developer convenience, so
>>> that running make install from testcases/kernel/syscalls/open doesn't
>>> require that I manually go into lib/ and testcases/kernel/include
>>> beforehand and run a make all, and have to duplicate a lot of
>>> unnecessary logic in the Makefiles.
>>>
>>> ===========================================================
>>> ADDITIONAL MAKE LOGIC GOES HERE
>>> ===========================================================
>>>
>>> Whatever you want to put in here that isn't provided with the defaults
>>> in env_post.mk, generic_leaf_target.inc, or generic_trunk_target.inc,
>>> so feel free to `use your imagination' as to whatever you may put in
>>> here, but the only cases that you should have to deal with are:
>>>
>>> 1. Multiple C files / objects -> one or more executables.
>>> 2. Items without implicit rule mappings, e.g. .c -> .o.
>>>
>>> ===========================================================
>>> POST-INCLUDE:
>>> ===========================================================
>>>
>>> - For all directory traversing Makefiles you include the `trunk
>>> target' Makefile:
>>>
>>> include $(top_srcdir)/include/mk/generic_trunk_target.mk
>>>
>>> - For all non-directory traversing Makefiles, you include the `leaf
>>> target' Makefile.
>>>
>>> include $(top_srcdir)/include/mk/generic_leaf_target.mk
>>>
>>> ===========================================================
>>>
>>> Now, to critique your proposed Makefiles...
>>>
>>> testcases/kernel/syscalls/rt_sigtimedwait/Makefile:
>>>
>>> +CFLAGS += -I../../../../include -Wall -O2 -DTEST_RT_SIGTIMEDWAIT
>>> +LDLIBS += -L../../../../lib -lltp
>>> +
>>> +SRCS    = $(wildcard *.c)
>>> +TARGETS = $(patsubst %.c,%,$(SRCS)) rt_sigtimedwait01
>>> +
>>> +all: $(TARGETS)
>>> +
>>> +rt_sigtimedwait01.o: ../sigwaitinfo/sigwaitinfo01.c
>>> +     $(CC) -c -o $@ $(CPPFLAGS) $(CFLAGS) $^
>>> +
>>> +install:
>>> +     @set -e; for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done
>>> +
>>> +clean:
>>> +     rm -f $(TARGETS)
>>>
>>> Given the above explanation, I would write this like the following
>>> (minus the licensing tort, and with improper indented vars -- bloody
>>> GMail :(...):
>>>
>>> =============================================
>>> top_srcdir ?= ../../../..
>>>
>>> include $(top_srcdir)/include/mk/testcases.mk
>>>
>>> # NOTE: Placement doesn't matter, but for readability and consistency
>>> it should go here.
>>> CPPFLAGS += -DTEST_RT_SIGTIMEDWAIT
>>>
>>> # NOTE: Placement for this Make target doesn't matter... just so long
>>> as it's defined in the Makefile.
>>> rt_sigtimedwait01: $(abs_srcdir)/../sigwaitinfo/sigwaitinfo01.c
>>>       $(COMPILE.o) $(OUTPUT_OPTION) $^
>>>
>>> # NOTE: Don't modify MAKE_TARGETS here because it isn't set yet, and
>>> the default is to pick up all existing C files in the
>>> # current directory and make them into single-source executables, e.g.
>>> # sigwaitinfo01.c -> sigwaitinfo01.o -> sigwaitinfo01 ;)...
>>>
>>> include $(top_srcdir)/include/mk/generic_leaf_target.mk
>>>
>>> MAKE_TARGETS += rt_sigtimedwait01
>>> =============================================
>>>
>>> Similar logic would be applied to your other Makefile, minus the
>>> CPPFLAGS assignment.
>>>
>>> Please note that your binary is no longer linked into
>>> $(abs_top_builddir)/testcases/bin -- it's instead install(1)'ed
>>> directly into $(DESTDIR)/$(prefix)/testcases/bin . This was done to
>>> facilitate proper installation by using the correct mode, and also to
>>> avoid broken/hacky symlinking operations.
>>>
>>> Hope that helps describe things a bit better... let me know if I
>>> should add this to a README or something...
>>>
>>>
>>
>> Thank you, it is definitely clearer now. I think it should be mentioned in
>> the README, including some list of the ltp makefile variables (like
>> $(abs_srcdir)). I'll wait with a new patch for the new build system to
>> appear in a release, though.
>>
>> What I still don't get is where does the ZIPFILE variable get its value
>> (this was the first place where I sought inspiration):
>>
>> jirka@debian:/usr/src/ltp-cvs$ fgrep -RI * -e ZIPFILE
>> testcases/commands/unzip/Makefile:$(INSTALL_TARGETS): $(ZIPFILE)
>> testcases/commands/unzip/Makefile:$(ZIPFILE): $(DIR)
>> jirka@debian:/usr/src/ltp-cvs$
>
> Ok, I'll add this information as an additional reference to README.mk-devel.
>
> ZIPFILE is most likely an ad-hoc variable defined in that Makefile
> that needs to be added to the new Makefile (it's missing from install
> and it's something that I forgot to add to TODO even though I noticed
> it once or twice -- I need to note all of the issues clearly this
> weekend after I go over the logs manually to ensure that I didn't miss
> anything by accident). Assuming that ZIPFILE's generated at build time
> (which it should be) you're fine getting away with ZIPFILE being a
> `bareword' value relative to the current directory. The only possible
> issue is that you'll have to ensure that the destination directory
> exists in order for out-of-build-tree support to continue to function
> properly (I don't expect people to get this correct all of the time,
> but I'd like to keep breakage down to a minimum because it impacts
> folks who cross-compile for multiple targets using the same src
> directory like my group). You can do this similar to the following:
>
> foo:
>    mkdir -p $@
> foo/bar: foo
>    # fake tab; do something to create foo/bar
>
> If foo/bar isn't a variable, then it can be expressed as:
>
> foo:
>    mkdir -p $@

Sorry. I meant:

.SECONDEXPANSION:
foo/bar: $$(@D)
    # fake tab; do something to create foo/bar

Most of the time this isn't the case though because specifying
INSTALL_TARGETS, uses generate_install_rule, which uses a variable for
the target value, and thus mucks up the `.SECONDEXPANSION:' call.

> Specifying the directory as a dependency of the target has the two
> following benefits:
> 1. Ensures that the dependency remains constant and the requirement is
> ensured from make (this is key).
> 2. Speeds up the build because adding comparable logic to each build
> and install rule (test -d foo || mkdir -p foo) I've discovered is
> considerably slower than being dependent on the directory and having
> make fill in the blanks as necessary. The difference was on the order
> of at least 1~2 mins from what I saw on the Cisco build servers I use
> and my personal machine.
>
> The dependency targets (e.g. foo) should be automatically available
> via some default logic called up in .../include/mk/env_post.mk using
> generate_install_rule_dir_dep .../include/mk/functions.mk, but I've
> run into some corner cases where this isn't correct (some of the
> INSTALL_TARGETS specified in Makefile.inc, IIRC), so I'll need to fix
> something minor after I stare at the problem from a different angle
> (it's most likely something really simple that I overlooked by
> accident).
>
> I've made some bad assumptions too that I've had to fix after testing
> in out-of-build-tree, so testing this new functionality is more
> complicated than traditional in-build-tree support, but if I can get a
> build-bot up and going for LTP which uses out-of-build-tree, this
> would be easy to automate longterm. I don't forsee completing this
> before the end of November though.
>
> So -- in summary: relative paths from current directory are ok -- just
> be sure that the directory is a dependency of the target and is
> created before the target is created or functional issues will occur
> (best case consistent build errors -- worst case race conditions in
> the source tree :[...).
>
> Cheers,
> -Garrett
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list