Re: [lmi] synchronizing wx and lmi for production

[Wendy Boutin]

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
http://biolpc22.york.ac.uk/pub/CVS_HEAD/wx-cvs-All.tar.bz2
> ? 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: 
http://biolpc22.york.ac.uk/pub/CVS_HEAD/files/wx-cvs-All-2005-08-06.tar.bz2

That clearly didn't work though:
  404 Not Found
  Sorry, The URL you requested
  
http://biolpc22.york.ac.uk/pub/CVS_HEAD/files/wx-cvs-All-2005-08-06.tar.bz2
  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
memory
> message or something like that?

I'm sure I don't have any memory and disk space problems. If I had the
memory
issue I expect I wouldn't have been able to build the dll using my first
method
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
building:

./bk-deps g++ -c -o monodll_ownerdrw.o -I.pch/wxprec_monodll
-D__WXMSW__       -I../src/png -I../src/zlib   -I../src/expat/lib
-DwxUSE_BASE=1 -DWXMAKINGDLL  -DWX_PRECOMP -DNO_GCC_PRAGMA
-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