From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Thu, 30 May 2013 09:59:48 +0200 Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2013-05-29 In-Reply-To: References: <20130530063005.259CD52C08A@lolut.humanoidz.org> Message-ID: <20130530095948.5bb31aaf@skate> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Dear Lionel Orry, On Thu, 30 May 2013 09:27:33 +0200, Lionel Orry wrote: > I noticed the error > (http://autobuild.buildroot.net/results/2379e4c18d6b7ecc48741c53b3f2c2445cf5e75c/build-end.log) > comes from the bundled 'src/cups/configure.in' which was generated by I guess you meant src/cups/Makefile.in, right? > a version of autotools which seems too old. The test of the existing > directory in the resulting Makefile was missing $(DESTDIR) prefix > while the $(MKDIR_P) afterwards was including it. > > I executed ./autogen.sh and the result install code changed radically, > $(MKDIR_P) not needing any directory existence test first. > > I don't know what the procedure is in those case. I suppose we should > suggest the gimp-print project devs to use a more recent autotools > version for next release? Yes, indeed. > Are we allowed to call autogen.sh ourselves? Preferably not autogen.sh. But you can add HOST_GUTENPRINT_AUTORECONF = YES in gutenprint.mk to achieve the same goal. We're already doing an autoreconf for the target build, so doing it on the host build shouldn't be a problem. Can you test this and see if it fixes the problem? If so submitting a patch would be nice. > Or provide a patch replacing the {configure,Makefile}.in files with > more recent ones? No, try with HOST_GUTENPRINT_AUTORECONF = YES. We don't want to carry patches against configure/Makefile.in, as those patches are generally really huge. Also, if you're working on gutenprint, it would be nice if the gutenprint-000-use-pregen-xmli18n-header.patch patch was rewritten to use a new option in configure.ac, so that this patch could potentially be upstreamed. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com