Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3F0F274F.3060700@seawood.org> Date: Fri, 11 Jul 2003 14:08:31 -0700 From: Christopher Seawood Reply-To: cls AT seawood DOT org User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030706 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: make 3.80 and VPATH References: <3F0DE2D4 DOT 8010801 AT seawood DOT org> In-Reply-To: <3F0DE2D4.8010801@seawood.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On Thu, 10 Jul 2003 18:18:15 -0400, Christopher Faylor wrote: >On Thu, Jul 10, 2003 at 03:04:04PM -0700, Christopher Seawood wrote: >>It appears that make 3.80 no longer translates the path in VPATH to a >>native cygwin path. Is this intentional? >> >>This causes a problem for objdir builds with Mozilla which uses win32 >>paths for VPATH, topsrcdir & srcdir. >> >>http://bugzilla.mozilla.org/show_bug.cgi?id=210393 > >Translated here for posterity: > >* cygwin has moved to make-3.8.0 whic fails trying to build mozilla. >the problem >* is they defaulted the make mode to --win32. Failure is: >* >* unable to find Makefile.in in obj-i586-pc-msvc >* >* which looks like a VPATH failure > >This bug report is gobbledegook. No details, poor assumptions. > >Sorry. Test case required. Explanation of how make is invoked >required. Yes, that was poor bug report based upon an irc conversation. The bug report was just for reference of where we're dealing with the problem with Mozilla. My original question still stands: Is it intentional that the paths set in VPATH are no longer translated to a native cygwin path? There's no good way to get you a testcase unless you're willing to download Mozilla and attempt to compile it. Here's the basic explanation of the problem: For each Makefile in the main Mozilla tree, srcdir & VPATH are set using the following pattern: topsrcdir = c:/root/mozilla srcdir = c:/root/mozilla VPATH = c:/root/mozilla Add subdirs to those paths as expected. When using make 3.80, if I run configure and make in c:/root/mozilla, everything should work fine as make automatically searches the current directory before looking at VPATH. However, if I build outside of the source tree, (say c:/root/obj-opt) then the rule which looks for updates to Makefile.in so that it can update the current Makefile will fail. That rule looks like: Makefile: Makefile.in @$(PERL) $(AUTOCONF_TOOLS)/make-makefile -t $(topsrcdir) -d $(DEPTH) Now, if I change the VPATH in the first Makefile to say: VPATH = /c/root/mozilla then make works fine for that directory. Yes, I did change my default cygdrive mount prefix. Make 3.79.1 does not have that problem. It automatically translated the paths in VPATH to a native cygwin path that was usable by make. Hence, the original question of was this intentional. (And in case anyone's wondering, we use the dos-drive paths because the primary supported win32 compiler is MSVC and we wanted to avoid needing to do unnecessary cygpath calls for each Makefile or file to be compiled.) - cls -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/