From: Natanael C. <nat...@gm...> - 2007-11-27 14:44:08
|
Hi, There was yet another race in the makefile. Adding the line as showed below will let you use all your cpu cores (and distcc) when building ipsec-tools. I'm a bit curious why you added the DISTCLEANFILES line in Makefile.am. >From the GNU Automake manual[1]: "The intermediate files generated by yacc (or lex) will be included in any distribution that is made. That way the user doesn't need to have yacc or lex." diff -bru ipsec-tools-0.7.orig/src/setkey/Makefile.am ipsec-tools-0.7/src/setkey/Makefile.am --- ipsec-tools-0.7.orig/src/setkey/Makefile.am 2007-11-27 13:07:35 +0000 +++ ipsec-tools-0.7/src/setkey/Makefile.am 2007-11-27 13:11:10 +0000 @@ -16,6 +16,8 @@ noinst_HEADERS = vchar.h extern.h man8_MANS = setkey.8 +token.c: parse.h + EXTRA_DIST = ${man8_MANS} sample-policy01.cf sample-policy02.cf sample.cf \ scriptdump.pl test-pfkey.c DISTCLEANFILES = token.c parse.c parse.h -nc [1] http://www.gnu.org/software/automake/manual/automake.html#Yacc-and-Lex |
From: Matthew G. <mg...@sh...> - 2007-11-27 22:31:25
|
Natanael Copa wrote: > Hi, > > There was yet another race in the makefile. Adding the line as showed > below will let you use all your cpu cores (and distcc) when building > ipsec-tools. > > I'm a bit curious why you added the DISTCLEANFILES line in Makefile.am. > I like you first patch and believe it should be integrated into CVS. Regarding the attached patch, the flex / bison generated configuration file parser unfortunately has issues. They build c files that include headers that are platform specific which is why we require the flex / bison step during the normal build process. It may be that the l & y files can be modified to build c files that are more platform agnostic but I don't think anyone has looked into this. There is also a problem with the dist target where the y & l files are not being cleaned correctly before generating the release archives. Both Yvan and I looked into this before the 0.7 release but were unable to coax the build process into handling this properly. It sounds like you have a decent amount of autconf experience. If you know proper way to force this behavior I would love to hear your input. Thanks, -Matthew |
From: Natanael C. <nat...@gm...> - 2007-11-29 10:46:08
|
On Tue, 2007-11-27 at 16:31 -0600, Matthew Grooms wrote: > Natanael Copa wrote: > > Hi, > > > > There was yet another race in the makefile. Adding the line as showed > > below will let you use all your cpu cores (and distcc) when building > > ipsec-tools. > > > > I'm a bit curious why you added the DISTCLEANFILES line in Makefile.am. > > > > I like you first patch and believe it should be integrated into CVS. Would be great! > Regarding the attached patch, the flex / bison generated configuration > file parser unfortunately has issues. They build c files that include > headers that are platform specific which is why we require the flex / > bison step during the normal build process. It may be that the l & y > files can be modified to build c files that are more platform > agnostic > but I don't think anyone has looked into this. Do you know what platforms are causing problems? I have some vmware test boxes here and it would be helpful if I could reproduce the problem I'm trying to fix. Is it src/setkey/token.l you are thinking of: #include "vchar.h" #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__linux__) || \ (defined(__APPLE__) && defined(__MACH__)) #include "parse.h" #else #include "y.tab.h" #endif or is bison/flex generating code that includes headers? > It may be that the l & y files can be modified to build c files that > are more platform agnostic but I don't think anyone has looked into > this. This is the most sane way to fix IMHO. > > There is also a problem with the dist target where the y & l files are > not being cleaned correctly before generating the release archives. The code above seems to be able to cause this problem yes. Should you delete y.tab.h or parse.h? > Both > Yvan and I looked into this before the 0.7 release but were unable to > coax the build process into handling this properly. It sounds like you > have a decent amount of autconf experience. probably not. I just happened to read the manual :) > If you know proper way to > force this behavior I would love to hear your input. I would rather try to find out how to ship proper genereated .c/.h files. I suspect the problem you are experiencing (without knowing exacly what the platform specific headers in generated files are about) is related to different versions of autotools (on different platforms). Might be you can kill the #if defined(...) clause above and just use #include "parse.h" if the host creating the dist package runs a recent version of autotools. I would likt to try to reproduce the platform specific problem in the generated files you have. What platform(s) is causing problems? > Thanks, > > -Matthew |