Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 67387 invoked from network); 20 Dec 2006 21:38:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Dec 2006 21:38:54 -0000 Received: (qmail 19804 invoked by uid 500); 20 Dec 2006 21:38:51 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 19776 invoked by uid 500); 20 Dec 2006 21:38:51 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 19767 invoked by uid 99); 20 Dec 2006 21:38:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 13:38:51 -0800 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MAILTO_TO_SPAM_ADDR,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 13:38:39 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gx98Y-0003kb-T0 for dev@harmony.apache.org; Wed, 20 Dec 2006 22:38:06 +0100 Received: from msfwpr01.ims.intel.com ([62.118.80.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Dec 2006 22:38:06 +0100 Received: from gshimansky by msfwpr01.ims.intel.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Dec 2006 22:38:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dev@harmony.apache.org From: Gregory Shimansky Subject: Re: [build] Downloading dependencies Date: Thu, 21 Dec 2006 00:37:46 +0300 Lines: 137 Message-ID: References: <8E389A5F2FEABA4CB1DEC35A25CB39CE88D8DB@mssmsx411> <45895A18.3030802@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: msfwpr01.ims.intel.com User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) In-Reply-To: <45895A18.3030802@pobox.com> Sender: news X-Virus-Checked: Checked by ClamAV on apache.org Geir Magnusson Jr. wrote: > Can we actually build w/ VS.NET 2005? No we can't. Too much has changed since VS.NET 2003, and even building classlib is a pain, I didn't even try drlvm. But I think we'll have to support VS.NET 2005 eventually. > if so, then search for both... No I just mentioned that if we some day support VS.NET we'll have to check for both msvcr71.dll and msvcr80.dll. > Gregory Shimansky wrote: >> Ivanov, Alexey A wrote: >>> In default installation WinXP does not have this library in system32. >>> This library is installed by Visual Studio 2003 and may be installed by >>> other software which was compiled with Visual Studio 2003 (which is >>> v7.1). Visual Studio 2002 (v7.0) has msvc70.dll, if I remember >>> correctly. >> >> >> Also if the person has VS.NET 2005 installed, the DLL name is >> msvcr80.dll. >> >>> That is it may happen system lacks for this DLL. And Microsoft >>> recommends avoiding copying DLLs to system32 when installing an >>> application. Thus we better distribute this DLL in snapshots and further >>> releases because users may not have it. >>> >>> On the other hand, if a person has Microsoft compiler installed, the DLL >>> will most likely be in system32. >>> >>> That's it. >>> -- >>> Alexey A. Ivanov >>> Intel Enterprise Solutions Software Division >>> >>> >>>> -----Original Message----- >>>> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com] >>>> Sent: Wednesday, December 20, 2006 8:49 AM >>>> To: dev@harmony.apache.org >>>> Subject: Re: [build] Downloading dependencies >>>> >>>> If this library exists in system32 then we do not need to download it >>>> or do any additional search. Linker will do it for us. >>>> So we can simple remove all mentions of this library from dependencies. >>>> >>>> But when I suggested this last time someone reported that he has MSVC >>>> but does not have this library... This looks really strange. >>>> >>>> We can remove this dependency and look... :) >>>> >>>> SY, Alexey >>>> >>>> 2006/12/20, Leo Li : >>>>> Yes, actually we can just get MSVC71.dll from the system32 directory >>> at >>>>> least from XP, but as for other windows versions I am not sure the >>> exact >>>>> version of MSVC DLL. So is it ok if we do not explicitly get it but >>> use >>>> it >>>>> while linking by the search path of the os system just like other >>>>> kernel32.dll? >>>>> >>>>> On 12/20/06, Geir Magnusson Jr. wrote: >>>>>> >>>>>> >>>>>> Stefano Mazzocchi wrote: >>>>>>> Geir Magnusson Jr. wrote: >>>>>>>> Do we really need to download this dll? Everyone who has the >>> MSVC >>>>>>>> installed should have it, right? >>>>>>> I don't care if it's downloaded, linked or magically generated >>> out of >>>>>>> looking into tea leaves, the problem is that the build needs >>> manual >>>>>>> intervention and this is not documented anywhere. >>>>>>> >>>>>>> We need to make sure that what we say you need to do is *only* >>> what >>>> you >>>>>>> need to do. Every other (undocumented step) is annoying and slows >>> our >>>>>>> community development down. >>>>>> Yeah, I get it. My point is that I'm still not convinced we need >>> this >>>>>> to be downloaded... >>>>>> >>>>>> So do we? >>>>>> >>>>>> geir >>>>>> >>>>>>>> geir >>>>>>>> >>>>>>>> >>>>>>>> Stefano Mazzocchi wrote: >>>>>>>>> Tim Ellison wrote: >>>>>>>>>> Stefano Mazzocchi wrote: >>>>>>>>>>> Mark Hindess wrote: >>>>>>>>>>>> I tried doing fetch-depends before rebuild but it would fail >>> or >>>>>>>>>>>> corrupt >>>>>>>>>>>> dependencies often enough that it caused more trouble than >>> it >>>>>> solved. >>>>>>>>>>>> I can try it again I suppose - IIRC it was ibiblio that was >>> the >>>>>> main >>>>>>>>>>>> problem and that might have been a temporary issue. >>>>>>>>>>> People, you do realize that if fetch-depends breaks that >>> often we >>>>>>>>>>> have a >>>>>>>>>>> bigger problem than just dealing with faulty updates? >>>>>>>>>>> >>>>>>>>>>> Imagine that every time fetch-depends doesn't work we lose >>> the >>>>>> ability >>>>>>>>>>> for some guy out there to contribute something to us. >>>>>>>>>>> >>>>>>>>>>> This is, from a community building perspective, a *way* >>> bigger >>>>>> problem >>>>>>>>>>> than if the JVM ran at all after it compiled!! >>>>>>>>>> I remember the discussion over the msvcr71.dll download. Have >>>> there >>>>>> been >>>>>>>>>> other problems? >>>>>>>>> it's still not fixed! >> >> > -- Gregory