[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] synchronizing wx and lmi for production

From: Wendy Boutin
Subject: Re: [lmi] synchronizing wx and lmi for production
Date: Mon, 15 Aug 2005 10:39:53 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

Vadim Zeitlin wrote:
> On Fri, 12 Aug 2005 16:00:58 -0400 "Boutin, Wendy"
<address@hidden> wrote:
> BW> At times I've resorted to using wx's nightly tarballs for testing.
> BW> The problem with that method is the archives are only available on
> BW> the server for seven days. In our business environment, it takes
> BW> longer than those seven days to test, accept, and then release your
> BW> changes to others for a formal upgrade and synchronization with lmi.
>  I think it's best to make available the latest wx version tested
> with/acceptable for lmi separately anyhow.

Agreed. If I let you know exactly which code I've tested and accept, are
you able to put it somewhere that will have a URL we can use for just lmi?

> BW> Although, the bigger problem is not having a stable URL that can be
> BW> used in our setup automation.
>  Hmm, what about
> ? I admit I haven't really ever used it but this URL seems to be quite
> permanent.

But wouldn't that give me newer code from one day to the next? That seems
to be the situation--I downloaded yesterday's and today's wx-cvs-All.tar.bz2
and they'redifferent. See, when I test a new wx update for use with lmi, I
really want to use the exact code I tested, not what might be a week or two
newer. For example, if I tested code before the changes that affected lmi's
'wx_workarounds.hpp', and released the URL suggested, I wouldn't have been
able to deal with the problem we had before I gave it to others.

When I first encountered the inability to retrieve the archive I tested, I
thought I'd be wise and manually modify the link to include the specific
date I wanted: 

That clearly didn't work though:
  404 Not Found
  Sorry, The URL you requested
  was not found on this server.

> BW> and made it this way:
> BW>   make >>buildlog 2>&1
> BW>
> BW> but that resulted in only these libraries:
> BW>   [hidden] /c/downloads/wxWidgets/build-msys/lib
> BW>   $ ls
> BW>   libwxexpat-2.6.a  libwxpng-2.6.a  libwxregex-2.6.a 
libwxzlib-2.6.a  wx
>  This is mysterious. Are you sure your linker didn't die with out of
> message or something like that?

I'm sure I don't have any memory and disk space problems. If I had the
issue I expect I wouldn't have been able to build the dll using my first
either. Although a careful inspection of my make output this time shows
I have
a compilation problem, which is probably what prevented the dll from

./bk-deps g++ -c -o monodll_ownerdrw.o -I.pch/wxprec_monodll
-D__WXMSW__       -I../src/png -I../src/zlib   -I../src/expat/lib
-Ilib/wx/include/msw-ansi-release-2.6 -I../include -O2 -DNO_GCC_PRAGMA
-Wall -Wundef -Wno-ctor-dtor-privacy ../src/msw/ownerdrw.cpp
../src/msw/ownerdrw.cpp: In member function `bool
wxOwnerDrawn::IsMenuItem() const':
../src/msw/ownerdrw.cpp:173: error: invalid conversion from `const
wxOwnerDrawn* const' to `wxOwnerDrawn*'
../src/msw/ownerdrw.cpp:173: error:   initializing argument 1 of
`typename __gnu_cxx::hashtable<_Value, _Value, _HashFcn,
std::_Identity<_Value>, _EqualKey, _Alloc>::size_type
__gnu_cxx::hash_set<_Value, _HashFcn, _EqualKey, _Alloc>::count(const
typename __gnu_cxx::hashtable<_Value, _Value, _HashFcn,
std::_Identity<_Value>, _EqualKey, _Alloc>::key_type&) const [with
_Value = wxOwnerDrawn*, _HashFcn = wxPointerHash, _EqualKey =
wxPointerEqual, _Alloc = std::allocator<wxOwnerDrawn*>]'
make: *** [monodll_ownerdrw.o] Error 1

reply via email to

[Prev in Thread] Current Thread [Next in Thread]