|
From: Gilles C. <gil...@xe...> - 2014-04-19 15:27:21
|
Hi, a minor modification is needed to allow building valgrind out of its source tree: --- orig.valgrind-3.9.0/Makefile.am 2013-10-23 12:50:02.000000000 +0200 +++ valgrind-3.9.0/Makefile.am 2014-03-15 00:35:27.044018414 +0100 @@ -64,7 +64,7 @@ CLEANFILES = default.supp default.supp: $(DEFAULT_SUPP_FILES) echo "# This is a generated file, composed of the following suppression rules:" > default.supp echo "# " $(DEFAULT_SUPP_FILES) >> default.supp - cat $(DEFAULT_SUPP_FILES) >> default.supp + cat $^ >> default.supp ## Preprend @PERL@ because tests/vg_regtest isn't executable ## Ensure make exits with error if PERL fails or post_regtest_checks fails. Regards. -- Gilles. |
|
From: Philippe W. <phi...@sk...> - 2014-04-19 15:39:50
|
On Sat, 2014-04-19 at 17:27 +0200, Gilles Chanteperdrix wrote:
> Hi,
>
> a minor modification is needed to allow building valgrind out of its
> source tree:
>
> --- orig.valgrind-3.9.0/Makefile.am 2013-10-23 12:50:02.000000000 +0200
> +++ valgrind-3.9.0/Makefile.am 2014-03-15 00:35:27.044018414 +0100
> @@ -64,7 +64,7 @@ CLEANFILES = default.supp
> default.supp: $(DEFAULT_SUPP_FILES)
> echo "# This is a generated file, composed of the following suppression rules:" > default.supp
> echo "# " $(DEFAULT_SUPP_FILES) >> default.supp
> - cat $(DEFAULT_SUPP_FILES) >> default.supp
> + cat $^ >> default.supp
>
> ## Preprend @PERL@ because tests/vg_regtest isn't executable
> ## Ensure make exits with error if PERL fails or post_regtest_checks fails.
>
> Regards.
3.9.0 is available since 31 October 2013, and up to now, it seems
it could be build by most (or all?) people.
Can you give more information about:
what do you mean exactly by "building valgrind out of its source tree" ?
why do you want to build it out of its source tree, if building it is
working ?
which OS ?
which distribution ?
what build error/error msg/... you have without the above change ?
Thanks
Philippe
|
|
From: Gilles C. <gil...@xe...> - 2014-04-19 15:54:07
|
Le 19/04/2014 17:40, Philippe Waroquiers a écrit : > On Sat, 2014-04-19 at 17:27 +0200, Gilles Chanteperdrix wrote: >> Hi, >> >> a minor modification is needed to allow building valgrind out of its >> source tree: >> >> --- orig.valgrind-3.9.0/Makefile.am 2013-10-23 12:50:02.000000000 +0200 >> +++ valgrind-3.9.0/Makefile.am 2014-03-15 00:35:27.044018414 +0100 >> @@ -64,7 +64,7 @@ CLEANFILES = default.supp >> default.supp: $(DEFAULT_SUPP_FILES) >> echo "# This is a generated file, composed of the following suppression rules:" > default.supp >> echo "# " $(DEFAULT_SUPP_FILES) >> default.supp >> - cat $(DEFAULT_SUPP_FILES) >> default.supp >> + cat $^ >> default.supp >> >> ## Preprend @PERL@ because tests/vg_regtest isn't executable >> ## Ensure make exits with error if PERL fails or post_regtest_checks fails. >> >> Regards. > 3.9.0 is available since 31 October 2013, and up to now, it seems > it could be build by most (or all?) people. > > Can you give more information about: > what do you mean exactly by "building valgrind out of its source tree" ? > why do you want to build it out of its source tree, if building it is > working ? > which OS ? > which distribution ? > what build error/error msg/... you have without the above change ? Building a project "out-of-tree" is a common feature for projects using the autotools, see for instance: http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html In a nut shell, by running the configure script from a build directory different from the sources directory, the program gets built in this build directory instead of inside the source tree. The reason I use this is that it allows me to build valgrind for different platforms from the same source tree, without duplicating or symlinking the source tree. The out-of-tree builds relies on make's VPATH variable. Makefiles are run from a build tree, which does not contain the sources, but make looks for the dependencies in the directory mentioned in the VPATH variable, and passes the complete path to make rules when the dependency is found in the VPATH tree. So, for instance, if a foo.supp exists in /tmp/bar and /tmp/qux/Makefile contains: DEFAULT_SUPP_FILES=foo.supp VPATH = /tmp/bar default.supp: $(DEFAULT_SUPP_FILES) echo $< Running "make default.supp" in /tmp/qux will print /tmp/bar/foo.supp instead of just foo.supp, IOW, the rule gets passed the full path of the dependency. Without this change, cat $(DEFAULT_SUPP_FILES) fails because the files are not found in the build tree. I understand if you do not want to support that feature, but since the modification to get it working is a one-liner, I assumed that it was an already supported feature, and that the fact that it did not work in 3.9.0 was an oversight. Regards. -- Gilles. |
|
From: Philippe W. <phi...@sk...> - 2014-04-19 16:09:52
|
On Sat, 2014-04-19 at 17:53 +0200, Gilles Chanteperdrix wrote: > L > > Can you give more information about: > > what do you mean exactly by "building valgrind out of its source tree" ? > > why do you want to build it out of its source tree, if building it is > > working ? > > which OS ? > > which distribution ? > > what build error/error msg/... you have without the above change ? > > Building a project "out-of-tree" is a common feature for projects using > the autotools, see for instance: > > http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html > > In a nut shell, by running the configure script from a build directory > different from the sources directory, the program gets built in this > build directory instead of inside the source tree. > > The reason I use this is that it allows me to build valgrind for > different platforms from the same source tree, without duplicating or > symlinking the source tree. > > The out-of-tree builds relies on make's VPATH variable. Makefiles are > run from a build tree, which does not contain the sources, but make > looks for the dependencies in the directory mentioned in the VPATH > variable, and passes the complete path to make rules when the dependency > is found in the VPATH tree. > > So, for instance, if a foo.supp exists in /tmp/bar and /tmp/qux/Makefile > contains: > > DEFAULT_SUPP_FILES=foo.supp > > VPATH = /tmp/bar > > default.supp: $(DEFAULT_SUPP_FILES) > echo $< > > Running "make default.supp" in /tmp/qux will print /tmp/bar/foo.supp > instead of just foo.supp, IOW, the rule gets passed the full path of the > dependency. > > Without this change, cat $(DEFAULT_SUPP_FILES) fails because the files > are not found in the build tree. > > I understand if you do not want to support that feature, but since the > modification to get it working is a one-liner, I assumed that it was an > already supported feature, and that the fact that it did not work in > 3.9.0 was an oversight. Thanks for the detailed explanation above. It looks effectively interesting to me to be able to use one source tree but build it in various other directories with different configure setup. My knowledge of autotools and the valgrind build system is quite elementary, so I cannot judge what are the implications of supporting this. I suppose it does not imply to use particularly recent versions of some tools ? I suggest you file a wishbug in bugzilla with the above explanation and your patch. You might as well complete your patch by updating the documentations giving the build instructions (i.e. adding a section or a paragraph in README explaining how to do a out of source tree build). Thanks for looking at this Philippe |
|
From: Gilles C. <gil...@xe...> - 2014-04-19 16:18:06
|
Le 19/04/2014 18:10, Philippe Waroquiers a écrit : > On Sat, 2014-04-19 at 17:53 +0200, Gilles Chanteperdrix wrote: >> L >>> Can you give more information about: >>> what do you mean exactly by "building valgrind out of its source tree" ? >>> why do you want to build it out of its source tree, if building it is >>> working ? >>> which OS ? >>> which distribution ? >>> what build error/error msg/... you have without the above change ? >> >> Building a project "out-of-tree" is a common feature for projects using >> the autotools, see for instance: >> >> http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html >> >> In a nut shell, by running the configure script from a build directory >> different from the sources directory, the program gets built in this >> build directory instead of inside the source tree. >> >> The reason I use this is that it allows me to build valgrind for >> different platforms from the same source tree, without duplicating or >> symlinking the source tree. >> >> The out-of-tree builds relies on make's VPATH variable. Makefiles are >> run from a build tree, which does not contain the sources, but make >> looks for the dependencies in the directory mentioned in the VPATH >> variable, and passes the complete path to make rules when the dependency >> is found in the VPATH tree. >> >> So, for instance, if a foo.supp exists in /tmp/bar and /tmp/qux/Makefile >> contains: >> >> DEFAULT_SUPP_FILES=foo.supp >> >> VPATH = /tmp/bar >> >> default.supp: $(DEFAULT_SUPP_FILES) >> echo $< >> >> Running "make default.supp" in /tmp/qux will print /tmp/bar/foo.supp >> instead of just foo.supp, IOW, the rule gets passed the full path of the >> dependency. >> >> Without this change, cat $(DEFAULT_SUPP_FILES) fails because the files >> are not found in the build tree. >> >> I understand if you do not want to support that feature, but since the >> modification to get it working is a one-liner, I assumed that it was an >> already supported feature, and that the fact that it did not work in >> 3.9.0 was an oversight. > Thanks for the detailed explanation above. > It looks effectively interesting to me to be able to use one source > tree but build it in various other directories with different configure > setup. > > My knowledge of autotools and the valgrind build system is quite > elementary, so I cannot judge what are the implications of supporting > this. I suppose it does not imply to use particularly recent > versions of some tools ? It implies to use a make tool which supports the VPATH variable, if you want to build the project out of its source tree. GNU make VPATH has been supporting VPATH for a long time, I do not know about other makes. > > I suggest you file a wishbug in bugzilla with the above explanation > and your patch. > You might as well complete your patch by updating the documentations > giving the build instructions (i.e. adding a section or a paragraph > in README explaining how to do a out of source tree build). Ok, will do. Regards. -- Gilles. |
|
From: Gilles C. <gil...@xe...> - 2014-04-19 17:05:26
|
Le 19/04/2014 18:10, Philippe Waroquiers a écrit : > On Sat, 2014-04-19 at 17:53 +0200, Gilles Chanteperdrix wrote: >> L >>> Can you give more information about: >>> what do you mean exactly by "building valgrind out of its source tree" ? >>> why do you want to build it out of its source tree, if building it is >>> working ? >>> which OS ? >>> which distribution ? >>> what build error/error msg/... you have without the above change ? >> >> Building a project "out-of-tree" is a common feature for projects using >> the autotools, see for instance: >> >> http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html >> >> In a nut shell, by running the configure script from a build directory >> different from the sources directory, the program gets built in this >> build directory instead of inside the source tree. >> >> The reason I use this is that it allows me to build valgrind for >> different platforms from the same source tree, without duplicating or >> symlinking the source tree. >> >> The out-of-tree builds relies on make's VPATH variable. Makefiles are >> run from a build tree, which does not contain the sources, but make >> looks for the dependencies in the directory mentioned in the VPATH >> variable, and passes the complete path to make rules when the dependency >> is found in the VPATH tree. >> >> So, for instance, if a foo.supp exists in /tmp/bar and /tmp/qux/Makefile >> contains: >> >> DEFAULT_SUPP_FILES=foo.supp >> >> VPATH = /tmp/bar >> >> default.supp: $(DEFAULT_SUPP_FILES) >> echo $< >> >> Running "make default.supp" in /tmp/qux will print /tmp/bar/foo.supp >> instead of just foo.supp, IOW, the rule gets passed the full path of the >> dependency. >> >> Without this change, cat $(DEFAULT_SUPP_FILES) fails because the files >> are not found in the build tree. >> >> I understand if you do not want to support that feature, but since the >> modification to get it working is a one-liner, I assumed that it was an >> already supported feature, and that the fact that it did not work in >> 3.9.0 was an oversight. > Thanks for the detailed explanation above. > It looks effectively interesting to me to be able to use one source > tree but build it in various other directories with different configure > setup. > > My knowledge of autotools and the valgrind build system is quite > elementary, so I cannot judge what are the implications of supporting > this. I suppose it does not imply to use particularly recent > versions of some tools ? > > I suggest you file a wishbug in bugzilla with the above explanation > and your patch. > You might as well complete your patch by updating the documentations > giving the build instructions (i.e. adding a section or a paragraph > in README explaining how to do a out of source tree build). > > Thanks for looking at this It is done with bug 333628. Note that the attached patch is for trunk, which required quite a few more changes. Note that a fix similar to mine had already been proposed since 3.6.0: https://bugs.kde.org/show_bug.cgi?id=256174 -- Gilles. |