|
From: <sv...@va...> - 2009-05-19 06:25:03
|
Author: bart Date: 2009-05-19 07:24:51 +0100 (Tue, 19 May 2009) New Revision: 9969 Log: Merged missing part of r9900 from the MESSAGING_TIDYUP branch. Modified: trunk/drd/tests/Makefile.am Modified: trunk/drd/tests/Makefile.am =================================================================== --- trunk/drd/tests/Makefile.am 2009-05-19 06:11:34 UTC (rev 9968) +++ trunk/drd/tests/Makefile.am 2009-05-19 06:24:51 UTC (rev 9969) @@ -116,7 +116,6 @@ pth_inconsistent_cond_wait.vgtest \ pth_mutex_reinit.stderr.exp \ pth_mutex_reinit.vgtest \ - pth_process_shared_mutex.c \ pth_process_shared_mutex.vgtest \ pth_process_shared_mutex.stderr.exp \ pth_spinlock.stderr.exp \ |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-19 06:48:01
|
On Tue, May 19, 2009 at 4:24 PM, <sv...@va...> wrote: > Author: bart > Date: 2009-05-19 07:24:51 +0100 (Tue, 19 May 2009) > New Revision: 9969 > > Log: > Merged missing part of r9900 from the MESSAGING_TIDYUP branch. > > Modified: > trunk/drd/tests/Makefile.am > > - pth_process_shared_mutex.c \ drd/tests/pth_process_shared_mutex.c still exists. Why was it removed from the Makefile.am? Nick |
|
From: Bart V. A. <bar...@gm...> - 2009-05-19 06:52:52
|
On Tue, May 19, 2009 at 8:47 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Tue, May 19, 2009 at 4:24 PM, <sv...@va...> wrote: >> Author: bart >> Date: 2009-05-19 07:24:51 +0100 (Tue, 19 May 2009) >> New Revision: 9969 >> >> Log: >> Merged missing part of r9900 from the MESSAGING_TIDYUP branch. >> >> Modified: >> trunk/drd/tests/Makefile.am >> >> - pth_process_shared_mutex.c \ > > drd/tests/pth_process_shared_mutex.c still exists. Why was it removed > from the Makefile.am? Is it necessary to include .c files in EXTRA_DIST ? Bart. |
|
From: Julian S. <js...@ac...> - 2009-05-19 07:26:46
|
On Tuesday 19 May 2009, Bart Van Assche wrote: > On Tue, May 19, 2009 at 8:47 AM, Nicholas Nethercote > > <n.n...@gm...> wrote: > > On Tue, May 19, 2009 at 4:24 PM, <sv...@va...> wrote: > >> Author: bart > >> Date: 2009-05-19 07:24:51 +0100 (Tue, 19 May 2009) > >> New Revision: 9969 > >> > >> Log: > >> Merged missing part of r9900 from the MESSAGING_TIDYUP branch. > >> > >> Modified: > >> trunk/drd/tests/Makefile.am > >> > >> - pth_process_shared_mutex.c \ > > > > drd/tests/pth_process_shared_mutex.c still exists. Why was it removed > > from the Makefile.am? > > Is it necessary to include .c files in EXTRA_DIST ? No. I think the .c files for the tarball are inferred from the names in check_PROGRAMS. Hmm, but then drd/tests/Makefile.am has various conditional additions to check_PROGRAMS: if HAVE_BOOST_1_35 check_PROGRAMS += boost_thread endif So if my theory is correct, then the .c files included in the tarball depends what the configure script on the machine running 'make dist' found. Which is obviously very bad. So, uh, once again confused by the build system. Nick, any ideas? J |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-19 07:32:30
|
On Tue, May 19, 2009 at 5:29 PM, Julian Seward <js...@ac...> wrote: >> >> Is it necessary to include .c files in EXTRA_DIST ? > > No. I think the .c files for the tarball are inferred from the names > in check_PROGRAMS. > > Hmm, but then drd/tests/Makefile.am has various conditional additions > to check_PROGRAMS: > > if HAVE_BOOST_1_35 > check_PROGRAMS += boost_thread > endif > > So if my theory is correct, then the .c files included in the tarball > depends what the configure script on the machine running 'make dist' > found. Which is obviously very bad. > > So, uh, once again confused by the build system. Nick, any ideas? Putting the .c file in EXTRA_DIST caused problems? Nick |
|
From: Julian S. <js...@ac...> - 2009-05-19 08:03:25
|
On Tuesday 19 May 2009, Nicholas Nethercote wrote:
> On Tue, May 19, 2009 at 5:29 PM, Julian Seward <js...@ac...> wrote:
> >> Is it necessary to include .c files in EXTRA_DIST ?
> >
> > No. I think the .c files for the tarball are inferred from the names
> > in check_PROGRAMS.
> >
> > Hmm, but then drd/tests/Makefile.am has various conditional additions
> > to check_PROGRAMS:
> >
> > if HAVE_BOOST_1_35
> > check_PROGRAMS += boost_thread
> > endif
> >
> > So if my theory is correct, then the .c files included in the tarball
> > depends what the configure script on the machine running 'make dist'
> > found. Which is obviously very bad.
> >
> > So, uh, once again confused by the build system. Nick, any ideas?
>
> Putting the .c file in EXTRA_DIST caused problems?
Er, no. Confusion all round :-) Let's start over.
The original change is the first chunk in r9900, viz:
Modified: branches/MESSAGING_TIDYUP/drd/tests/Makefile.am
===================================================================
--- branches/MESSAGING_TIDYUP/drd/tests/Makefile.am 2009-05-18 08:19:24
UTC (rev 9899)
+++ branches/MESSAGING_TIDYUP/drd/tests/Makefile.am 2009-05-18 09:22:39
UTC (rev 9900)
@@ -115,7 +115,7 @@
pth_inconsistent_cond_wait.stderr.exp2 \
pth_inconsistent_cond_wait.vgtest \
pth_process_shared_mutex.vgtest \
- pth_process_shared_mutex.c \
+ pth_process_shared_mutex.stderr.exp \
pth_spinlock.stderr.exp \
pth_spinlock.vgtest \
qt4_mutex.stderr.exp \
I did this because, when trying to unbreak make dist on
branches/MESSAGING_TIDYUP, pth_process_shared_mutex.stderr.exp
was not in the tarball. So I edited the Makefile.am as above,
and added it (to EXTRA_DIST). But I noticed also that
pth_process_shared_mutex.c was in the list, and thought, hmm,
that's wrong. So I just changed the ending from .c to .stderr.exp,
giving the above delta.
Anyway, this leads to the current question, which is what to do about
the sources for check_PROGRAMS components which are only conditionally
defined, eg
if HAVE_PTHREAD_BARRIER
check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit
endif
Because pth_process_shared_mutex is unconditionally in check_PROGRAMS,
I think it is not necessary to include pth_process_shared_mutex.c
in EXTRA_DIST. But for sources corresponding to (eg) matinv pth_barrier
pth_barrier_race pth_barrier_reinit, I am suggesting that perhaps we do
need to include their .c files in EXTRA_DIST, because what if the
machine running "make dist" did not, for example, HAVE_PTHREAD_BARRIER?
J
|
|
From: Bart V. A. <bar...@gm...> - 2009-05-19 17:02:46
|
On Tue, May 19, 2009 at 10:06 AM, Julian Seward <js...@ac...> wrote: > Anyway, this leads to the current question, which is what to do about > the sources for check_PROGRAMS components which are only conditionally > defined, eg > > if HAVE_PTHREAD_BARRIER > check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit > endif > > Because pth_process_shared_mutex is unconditionally in check_PROGRAMS, > I think it is not necessary to include pth_process_shared_mutex.c > in EXTRA_DIST. But for sources corresponding to (eg) matinv pth_barrier > pth_barrier_race pth_barrier_reinit, I am suggesting that perhaps we do > need to include their .c files in EXTRA_DIST, because what if the > machine running "make dist" did not, for example, HAVE_PTHREAD_BARRIER? By the way, the issue that the result of "make dist" depends on the machine "make dist" is run on does not only apply to the source code of DRD regression tests but also to the source code of the Helgrind regression tests. Bart. |
|
From: Julian S. <js...@ac...> - 2009-05-19 19:00:45
|
> > Because pth_process_shared_mutex is unconditionally in check_PROGRAMS, > > I think it is not necessary to include pth_process_shared_mutex.c > > in EXTRA_DIST. But for sources corresponding to (eg) matinv pth_barrier > > pth_barrier_race pth_barrier_reinit, I am suggesting that perhaps we do > > need to include their .c files in EXTRA_DIST, because what if the > > machine running "make dist" did not, for example, HAVE_PTHREAD_BARRIER? > > By the way, the issue that the result of "make dist" depends on the > machine "make dist" is run on does not only apply to the source code > of DRD regression tests but also to the source code of the Helgrind > regression tests. Ah, ok. That's useful to know. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-20 00:05:34
|
On Tue, May 19, 2009 at 6:06 PM, Julian Seward <js...@ac...> wrote: > Anyway, this leads to the current question, which is what to do about > the sources for check_PROGRAMS components which are only conditionally > defined, eg > > if HAVE_PTHREAD_BARRIER > check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit > endif Maybe we need this: if HAVE_PTHREAD_BARRIER check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit else EXTRA_DIST += matinv.c pth_barrier.c pth_barrier_race.c pth_barrier_reinit.c endif N |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-29 07:06:14
|
On Wed, May 20, 2009 at 10:05 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Tue, May 19, 2009 at 6:06 PM, Julian Seward <js...@ac...> wrote: >> Anyway, this leads to the current question, which is what to do about >> the sources for check_PROGRAMS components which are only conditionally >> defined, eg >> >> if HAVE_PTHREAD_BARRIER >> check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit >> endif > > Maybe we need this: > > if HAVE_PTHREAD_BARRIER > check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit > else > EXTRA_DIST += matinv.c pth_barrier.c pth_barrier_race.c pth_barrier_reinit.c > endif I just looked into this. It seems that automake includes the source files for the programs listed in check_PROGRAMS above, even if HAVE_PTHREAD_BARRIER isn't true. Which makes sense really, otherwise everyone would face this problem. In other words, we don't have to do anything. Hooray! Nick |
|
From: Bart V. A. <bar...@gm...> - 2009-05-29 08:06:16
|
On Fri, May 29, 2009 at 9:06 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, May 20, 2009 at 10:05 AM, Nicholas Nethercote > <n.n...@gm...> wrote: >> On Tue, May 19, 2009 at 6:06 PM, Julian Seward <js...@ac...> wrote: >>> Anyway, this leads to the current question, which is what to do about >>> the sources for check_PROGRAMS components which are only conditionally >>> defined, eg >>> >>> if HAVE_PTHREAD_BARRIER >>> check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit >>> endif >> >> Maybe we need this: >> >> if HAVE_PTHREAD_BARRIER >> check_PROGRAMS += matinv pth_barrier pth_barrier_race pth_barrier_reinit >> else >> EXTRA_DIST += matinv.c pth_barrier.c pth_barrier_race.c pth_barrier_reinit.c >> endif > > I just looked into this. It seems that automake includes the source > files for the programs listed in check_PROGRAMS above, even if > HAVE_PTHREAD_BARRIER isn't true. Which makes sense really, otherwise > everyone would face this problem. > > In other words, we don't have to do anything. Hooray! Thanks for figuring this out. Bart. |