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 13:35:12 GMT

On Dec 25, 2006, at 7:15 AM, Alexey Petrenko wrote:

> We don't really need it in class library build (if we have it in  
> system32).
> We just need it in bin directory of hdk snapshots.

Right - and some people such as those focused on classlibrary-only  
therefore need to have it in

    classlib/trunk/deploy/jdk/jre/bin

so they can then drop their VM in (say, J9) and have things work.

So while I too think that the federated build is the only rational  
way to do things :) it's still true that people will not be using it  
when doing classlib work.  So I think it's useful that the copy of  
the dll also happen in the classlib build.

geir

>
> SY, Alexey
>
> 2006/12/25, Geir Magnusson Jr. <geir@pobox.com>:
>>
>> 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