|
From: Josef W. <Jos...@gm...> - 2005-11-15 09:46:17
|
Hi, I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package. These means that I have two similar, but different build targets which are conditionally built dependent on the Valgrind installation found: for VG 3.0, I build a shared library, for VG 3.1 a static linked binary. Currently, I try to use two different subdirs/Makefile.am's for this, using in the toplevel Makefile.am SUBDIRS = $(CG_SRCDIR) CG_SRCDIR is set to the right build directory dependent on what configure detected. The problem is that "make dist" only includes one of the build dirs, not both. Ideas? Thanks, Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 10:48:08
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package.
> These means that I have two similar, but different build targets
> which are conditionally built dependent on the Valgrind installation
> found: for VG 3.0, I build a shared library, for VG 3.1 a static linked
> binary.
>
> Currently, I try to use two different subdirs/Makefile.am's for this,
> using in the toplevel Makefile.am
>
> SUBDIRS = $(CG_SRCDIR)
>
> CG_SRCDIR is set to the right build directory dependent on what
> configure detected.
Sounds horrid, but still... Sounds like I'm going to have fun getting
my in tree builds to work ;-)
> The problem is that "make dist" only includes one of the build dirs,
> not both.
Indeed - it will only include the one you've configured for.
The solution is to set DIST_SUBDIRS to list both directories.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-15 15:15:08
|
On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package. Why? Getting the automake/autoconf stuff right is hard enough... why make it even more difficult for yourself? :) Nick |
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:45:24
|
On Tuesday 15 November 2005 16:14, Nicholas Nethercote wrote: > On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > > > I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package. > > Why? Getting the automake/autoconf stuff right is hard enough... why make > it even more difficult for yourself? :) I do not want to do maintenance releases for a "Callgrind/VG 3.0". E.g. Callgrind 0.9.12 supports all stable VG releases from 2.0. This proved useful in the past. VG30 vs. 31 is special, because of the move to static linked tools. But regarding the tool code, it is not much difference, so I really want to keep one package. As long as it works, this seems to be the best way. If you look at the mailing list, there often are support queries for older VG releases, coming with some distro. E.g. if someone with Suse 10.0 is interested in Callgrind, he does not have to update to VG 3.1 before running newest Callgrind. Josef |
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:50:08
|
On Tuesday 15 November 2005 11:47, Tom Hughes wrote: > > Currently, I try to use two different subdirs/Makefile.am's for this, > > using in the toplevel Makefile.am > > > > SUBDIRS = $(CG_SRCDIR) > > > > CG_SRCDIR is set to the right build directory dependent on what > > configure detected. > > Sounds horrid, but still... I am not a automake/conf guru. Perhaps only one Makefile.am is better. But this would need conditional targets? Is this supported? > Sounds like I'm going to have fun getting > my in tree builds to work ;-) Why? > The solution is to set DIST_SUBDIRS to list both directories. Ah, thanks! Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 16:58:22
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 15 November 2005 11:47, Tom Hughes wrote:
>> > Currently, I try to use two different subdirs/Makefile.am's for this,
>> > using in the toplevel Makefile.am
>> >
>> > SUBDIRS = $(CG_SRCDIR)
>> >
>> > CG_SRCDIR is set to the right build directory dependent on what
>> > configure detected.
>>
>> Sounds horrid, but still...
>
> I am not a automake/conf guru.
> Perhaps only one Makefile.am is better. But this would need
> conditional targets? Is this supported?
You can possibly do it with automake conditionals, though you may need
automake 1.7 for that - valgrind does that now though anyway. See any
of the tools for how noinst_PROGRAMS is defined.
>> Sounds like I'm going to have fun getting
>> my in tree builds to work ;-)
>
> Why?
It's a horrid hack I use to build callgrind and valgrind all as part
of a single RPM so I have to patch callgrind to build against the
uninstalled version of valgrind in my build tree and not try and run
the installed valgrind to find out what version it is...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 17:44:29
|
On Tuesday 15 November 2005 17:58, Tom Hughes wrote: > You can possibly do it with automake conditionals, though you may need > automake 1.7 for that - valgrind does that now though anyway. See any > of the tools for how noinst_PROGRAMS is defined. If have a target install-exec-local: $(INSTALL_PROGRAM) ./callgrind \ $(DESTDIR)$(valdir)/@VG_ARCH@-@VG_OS@ This should be done only for VG31. Is it enough to put if BUILD_FOR_VG30 ... endif around it? > It's a horrid hack I use to build callgrind and valgrind all as part > of a single RPM so I have to patch callgrind to build against the > uninstalled version of valgrind in my build tree and not try and run > the installed valgrind to find out what version it is... Wow. Perhaps callgrinds configure should get an option --uninstalled-vg-path=... to compile against an uninstalled VG? Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 17:55:04
Attachments:
callgrind-withsource.patch
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 15 November 2005 17:58, Tom Hughes wrote:
> > You can possibly do it with automake conditionals, though you may need
> > automake 1.7 for that - valgrind does that now though anyway. See any
> > of the tools for how noinst_PROGRAMS is defined.
>
> If have a target
>
> install-exec-local:
> $(INSTALL_PROGRAM) ./callgrind \
> $(DESTDIR)$(valdir)/@VG_ARCH@-@VG_OS@
>
> This should be done only for VG31.
> Is it enough to put
>
> if BUILD_FOR_VG30
> ...
> endif
>
> around it?
Probably. That's only an installation target though, presumably
somewhere there is a build target as well.
> > It's a horrid hack I use to build callgrind and valgrind all as part
> > of a single RPM so I have to patch callgrind to build against the
> > uninstalled version of valgrind in my build tree and not try and run
> > the installed valgrind to find out what version it is...
>
> Wow.
The reason I do it is because otherwise I have to build valgrind on
all the different systems then go round and install it before I can
build callgrind. I have a script to do builds across all our platforms
but not one to do installs so having to install valgrind before
building callgrind is a pain for me.
> Perhaps callgrinds configure should get an option
> --uninstalled-vg-path=...
> to compile against an uninstalled VG?
Attached is the patch I used for 3.0.1 with callgrind 0.10.0 that
adds a --with-source flag. Not sure if it works without that or not
as I never really tried it. It might well be a bit hacky as well...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|