harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [build] Downloading dependencies
Date Mon, 25 Dec 2006 12:11:03 GMT

On Dec 25, 2006, at 4:47 AM, Alexey Petrenko wrote:

> OK, I'll remove msvcr71.dll dependency from class library.
> Geir, could you add it to federated build?

Yes, I suppose that's the right place to deal with the problem,  
although since people can simply get a HDK and drop a VM into it  
there for testing.... don't we need it in the classlib build as well?

geir

>
> SY, Alexey
>
> 2006/12/25, Ivanov, Alexey A <alexey.a.ivanov@intel.com>:
>> >-----Original Message-----
>> >From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>> >Sent: Saturday, December 23, 2006 3:25 PM
>> >To: dev@harmony.apache.org
>> >Subject: Re: [build] Downloading dependencies
>> >
>> >
>> >On Dec 21, 2006, at 4:24 AM, Alexey Petrenko wrote:
>> >
>> >> Yes, we do not really need it while Harmony development. I've said
>> >> this few times.
>> >> But we definitely need this dll while building distribution  
>> package.
>> >>
>> >> So copying it while build will not break anything in  
>> development but
>> >> will make life easier for distribution build.
>> >
>> >So to keep things clean... why not change things so that the build
>> >brings in the dll that is being used by the build?  IOW, completely
>> >remove it as an external dependency, and simply copy it when making
>> >the build.  That way we are sure that the dll that is included is  
>> the
>> >right one.
>>
>> This will be the best solution.
>>
>> Regards,
>> Alexey.
>>
>> >
>> >geir
>> >
>> >>
>> >> SY, Alexey
>> >>
>> >> 2006/12/21, Ivanov, Alexey A <alexey.a.ivanov@intel.com>:
>> >>> >-----Original Message-----
>> >>> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
>> >>> >Sent: Wednesday, December 20, 2006 8:49 PM
>> >>> >To: dev@harmony.apache.org
>> >>> >Subject: Re: [build] Downloading dependencies
>> >>> >
>> >>> >2006/12/20, Stefano Mazzocchi <stefano@apache.org>:
>> >>> >> 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.
>> >>> >> ah, that might be why! I had 2005 installed
>> >>> >:)
>> >>>
>> >>> I believe this DLL is not needed during build, no matter what
>> >>> compiler
>> >>> do you use. The compiler itself will find the correct DLL (it  
>> should
>> >>> install it into system32).
>> >>>
>> >>> We will need the correct DLL to be able to run natives. I mean we
>> >>> should
>> >>> have the DLL in snapshots which are targeted at end-users who may
>> not
>> >>> have any version of Visual Studio or Compiler installed. And we
>> >>> should
>> >>> provide the correct version of the DLL which corresponds to the
>> >>> version
>> >>> of the compiler that was used to build the snapshots.
>> >>>
>> >>> I even think that this DLL is not needed in deploy directory  
>> either:
>> >>> when we start VM, the system will link with the DLL from system32
>> >>> which
>> >>> is there if one compiled the natives oneself.
>> >>>
>> >>> Am I wrong?
>> >>>
>> >>>
>> >>> Alexey, why do we need the DLL while building?
>> >>>
>> >>>
>> >>> Regards,
>> >>> Alexey.
>> >>>
>> >>>
>> >>> >
>> >>> >SY, Alexey
>> >>> >
>> >>> >> >> 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 <liyilei1979@gmail.com>:
>> >>> >> >>>>  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. <geir@pobox.com>
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!
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Stefano.
>> >>> >>
>> >>> >>
>> >>>
>> >>> --
>> >>> Alexey A. Ivanov
>> >>> Intel Enterprise Solutions Software Division
>> >>>
>>
>> --
>> Alexey A. Ivanov
>> Intel Enterprise Solutions Software Division
>>


Mime
View raw message