wxlua-users

[Wxlua-users] wxLua packaging

[Francesco M. <f18...@ya...>]

Hi,
    as you can see, I start to think to the first release of wxLua ;)

So, let's discuss this issue.

I'd make a total of 4 releases:

1) a win32 MSI install package. This can be generated using InnoSetup 
and it should distribute all wxLua tree including EXE, doxygen generated 
docs and .lib files, all built in release mode, possibly against a 
static build of wxWidgets.

2) a source package with doxygen generated documentation.

3) an Autopackage for 32bit linuxes. it should distribute exactly the 
same things as the win32 MSI package, possibly built with latests GCC ( 
I think that building with 4.0.x lets us to support all gcc versions 
after 3.2.3 [which broke the ABI, IIRC]).

4) an autopackage for 64bit linuxes.

I think there's no need to discuss about #2 ;)
About #3, #4, I sincerely admit I've never autopackaged anything up to 
now but the project looks *very* promising and it lets us to be 
indipendent from distro-specific systems like RPM, DEB, EBUILD, etc. but 
still provide binaries of the project.

What's your opinion ?


Francesco

Re: [Wxlua-users] wxLua packaging

[John L. <jla...@gm...>]

On 2/12/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>     as you can see, I start to think to the first release of wxLua ;)

It probably should happen soon enough. I need to remove and cleanup a
little more duplicate code, but I think that everything works well
enough.

> So, let's discuss this issue.
>
> I'd make a total of 4 releases:
>
> 1) a win32 MSI install package. This can be generated using InnoSetup
> and it should distribute all wxLua tree including EXE, doxygen generated
> docs and .lib files, all built in release mode, possibly against a
> static build of wxWidgets.

Maybe it would be easier to just have a zip? Developers will probably
be used to unzipping things where they want them. The final product
the wxLua.exe could use an installer, but I know nothing about using
them.

> 2) a source package with doxygen generated documentation.
>
> 3) an Autopackage for 32bit linuxes. it should distribute exactly the
> same things as the win32 MSI package, possibly built with latests GCC (
> I think that building with 4.0.x lets us to support all gcc versions
> after 3.2.3 [which broke the ABI, IIRC]).
>
> 4) an autopackage for 64bit linuxes.
>
> I think there's no need to discuss about #2 ;)
> About #3, #4, I sincerely admit I've never autopackaged anything up to
> now but the project looks *very* promising and it lets us to be
> indipendent from distro-specific systems like RPM, DEB, EBUILD, etc. but
> still provide binaries of the project.
>
> What's your opinion ?

I unfortunately know almost nothing about this. Autopackage will build
the spec files for RPMs and the other packages? I'll google it.

-John Labenski

Re: [Wxlua-users] wxLua packaging

[k. h. <kla...@nl...>]

John Labenski wrote:

>On 2/12/06, Francesco Montorsi <f18...@ya...> wrote:
>  
>
>>Hi,
>>    as you can see, I start to think to the first release of wxLua ;)
>>    
>>
>
>It probably should happen soon enough. I need to remove and cleanup a
>little more duplicate code, but I think that everything works well
>enough.
>  
>
It would be great, if you could manage the problem with namespaces in 
wxluacan.
Or if not so possible, before the release change the namespace to wx 
instead of wxluacan.
I am confused what is in CVS by now.

But this does not work, when run from the run script menu, it still 
calls function that are wrong.

    function AddSome()
        for list = 1, 10 do
            canvas = wxluacan.GetCan()
            canobjrect = wxluacan.wxlCanObjRect( 30+list*2, 40+list*3, 
100, 20)
            canvas:AddObject(  canobjrect )
        end
    end

wx.wxMessageBox(  "Now we will add two object to the canvas",
                                                "wxLuaCan Message",
                                                wx.wxYES_NO + wx.wxCENTRE)

canvas = wxluacan.GetCan()
canobjrect = wxluacan.wxlCanObjRect( 30, 40, 100, 20)
canvas:AddObject(  canobjrect )
canobjrect:SetPending( true )
AddSome()

regards,

Klaas

-- 
Unclassified

[Wxlua-users] Re: wxLua packaging

[Francesco M. <f18...@ya...>]

Hi,

Francesco Montorsi ha scritto:
> Hi,
>    as you can see, I start to think to the first release of wxLua ;)
> 
> So, let's discuss this issue.
> 
> I'd make a total of 4 releases:
> 
> 1) a win32 MSI install package. This can be generated using InnoSetup 
> and it should distribute all wxLua tree including EXE, doxygen generated 
> docs and .lib files, all built in release mode, possibly against a 
> static build of wxWidgets.
I have created this package and added it to CVS.
I also uploaded an experimental setup installer for win32 at

     http://wxlua.sourceforge.net/wxLua-2.6.2.1-setup.exe

I've tried it out for a while and it works nice. If someone can test it 
and confirms it installs wxLua and that it works it would be good.
However it needs:

1) to have all wxLua sample files to be renamed with .wxlua extension 
(.wx.lua extension is not good for windows when you need to associate a 
program to it - at least programmatically)

2) to have wxLuaEditor able to open .wxlua files which are passed to it 
as first parameter... John, can you do that ?

BTW I think that all wxLua samples should be reviewed as they look quite 
old and some doesn't work smoothly...

Is there any other problem which must be solved before the release ?
Besides the website completion, obviously... (any help writing pages 
would be very appreciated ;))

Francesco

Re: [Wxlua-users] Re: wxLua packaging

[John L. <jla...@gm...>]

On 2/20/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> > Hi,
> >    as you can see, I start to think to the first release of wxLua ;)

Thanks!

> > So, let's discuss this issue.
> >
> > I'd make a total of 4 releases:
> >
> > 1) a win32 MSI install package. This can be generated using InnoSetup
> > and it should distribute all wxLua tree including EXE, doxygen generate=
d
> > docs and .lib files, all built in release mode, possibly against a
> > static build of wxWidgets.
> I have created this package and added it to CVS.
> I also uploaded an experimental setup installer for win32 at
>
>      http://wxlua.sourceforge.net/wxLua-2.6.2.1-setup.exe
>
> I've tried it out for a while and it works nice. If someone can test it
> and confirms it installs wxLua and that it works it would be good.
> However it needs:
>
> 1) to have all wxLua sample files to be renamed with .wxlua extension
> (.wx.lua extension is not good for windows when you need to associate a
> program to it - at least programmatically)

That will make syntax highlighting editors not be able to immediately
hilight it for lua. I'm not sure that's a good idea.

> 2) to have wxLuaEditor able to open .wxlua files which are passed to it
> as first parameter... John, can you do that ?

If you really think that that's a good idea, I don't think so.

> BTW I think that all wxLua samples should be reviewed as they look quite
> old and some doesn't work smoothly...

Heh, there are more samples from the original distribution, but I just
took the ones that work out of the box. But I do agree that they are
not very exciting.

> Is there any other problem which must be solved before the release ?
> Besides the website completion, obviously... (any help writing pages
> would be very appreciated ;))

I will try to put some text up there tomorrow.

-John Labenski

Re: [Wxlua-users] Re: wxLua packaging

[k. h. <kla...@nl...>]

Francesco Montorsi wrote:

>
> Is there any other problem which must be solved before the release ?
>
What should compile in VC when using batch build?

( I read that VC2005 is for free now, is it true?? )
If so we might pay less attention to VC6 which is not to good i think.

Did you both compile all flavours in batch build using 2005 ?
If so do they compile well?

I myself get linking errors, etc. i wonder if this is because of VC6 or 
soemthing else.

Klaas

wx_object.cpp
..\..\..\modules\wxlua/include/wxlstate.h(184) : warning C4251: 
'm_coroutineStates' : class 'wxArrayLuaState' needs to have 
dll-interface to be used by clients of class 'wxLuaStateRefData'
        ..\..\..\modules\wxlua/include/wxlstate.h(156) : see declaration 
of 'wxArrayLuaState'
..\..\..\modules\wxlua/include/wxlstate.h(190) : warning C4251: 
's_wxHashMapLuaStateRefData' : class 'wxHashMapLuaStateRefData' needs to 
have dll-interface to be used by clients of class 'wxLuaStateRefData'
        ..\..\..\modules\wxlua/include/wxlstate.h(159) : see declaration 
of 'wxHashMapLuaStateRefData'
..\..\..\modules\wxluadebug/include/wxldebug.h(108) : warning C4275: non 
dll-interface class 'wxLuaDebugDataItemArray' used as base for 
dll-interface class 'wxLuaDebugData'
        ..\..\..\modules\wxluadebug/include/wxldebug.h(100) : see 
declaration of 'wxLuaDebugDataItemArray'


-- 
Unclassified

[Wxlua-users] Re: wxLua packaging

[Francesco M. <f18...@ya...>]

Hi,

k. holwerda ha scritto:
>> Is there any other problem which must be solved before the release ?
>>
> What should compile in VC when using batch build?
> 
> ( I read that VC2005 is for free now, is it true?? )
the express edition is free but it has some limited features.
Nonetheless it's a great thing: something free from ms ;)


> If so we might pay less attention to VC6 which is not to good i think.
I think MSVC6 is going to be completely 'deprecated' in few years...
maybe we could:
a) move msvc6 project files in the new build\msvc6 folders
b) convert msvc6 project files and add them in the build\msvc7/8 folders

Unfortunately AFAIK MSVC.NET and MSVC2005 use two different formats... 
I'm going to see if I can add these formats to bakefile.


> Did you both compile all flavours in batch build using 2005 ?
 > If so do they compile well?
I don't like to do batch builds with IDE.
I usually use makefiles for that and makefile.vc allowed me to compile 
wxLua with any combination of options I've tried so far...



> I myself get linking errors, etc. i wonder if this is because of VC6 or 
> soemthing else.
> 
> Klaas
> 
> wx_object.cpp
> ...\..\..\modules\wxlua/include/wxlstate.h(184) : warning C4251: 
> 'm_coroutineStates' : class 'wxArrayLuaState' needs to have 
> dll-interface to be used by clients of class 'wxLuaStateRefData'
>        ..\..\..\modules\wxlua/include/wxlstate.h(156) : see declaration 
> of 'wxArrayLuaState'
> ...\..\..\modules\wxlua/include/wxlstate.h(190) : warning C4251: 
> 's_wxHashMapLuaStateRefData' : class 'wxHashMapLuaStateRefData' needs to 
> have dll-interface to be used by clients of class 'wxLuaStateRefData'
>        ..\..\..\modules\wxlua/include/wxlstate.h(159) : see declaration 
> of 'wxHashMapLuaStateRefData'
> ...\..\..\modules\wxluadebug/include/wxldebug.h(108) : warning C4275: 
> non dll-interface class 'wxLuaDebugDataItemArray' used as base for 
> dll-interface class 'wxLuaDebugData'
>        ..\..\..\modules\wxluadebug/include/wxldebug.h(100) : see 
> declaration of 'wxLuaDebugDataItemArray'
these are warnings, what about the linking errors?

Francesco

Re: [Wxlua-users] Re: wxLua packaging

[klaas.holwerda <kho...@xs...>]

Hi,

Francesco Montorsi wrote:
>
>> If so we might pay less attention to VC6 which is not to good i think.
> I think MSVC6 is going to be completely 'deprecated' in few years...
That is what i think too. But at the moment?
> maybe we could:
> a) move msvc6 project files in the new build\msvc6 folders
> b) convert msvc6 project files and add them in the build\msvc7/8 folders
Good idea.
>
> Unfortunately AFAIK MSVC.NET and MSVC2005 use two different formats... 
> I'm going to see if I can add these formats to bakefile.
Arrg!
>
>
>> Did you both compile all flavours in batch build using 2005 ?
> > If so do they compile well?
> I don't like to do batch builds with IDE.
I know.
> I usually use makefiles for that and makefile.vc allowed me to compile 
> wxLua with any combination of options I've tried so far...
With project files we must get it too work too, this is what the general 
user will use.
Especially when debugging i prefer much to debug inside the linked 
libraries and all.
That is often how i understand where the problems are.

>
>
>
>> I myself get linking errors, etc. i wonder if this is because of VC6 
>> or soemthing else.
I put the two logs files here.

First i tried to make wxStedit which i downloaded at wxCode. ( I tried 
first CVS but had problems so i downloaded it eventually.)
It is not clear yet from install.html which one i should get.
That i tried to build without success.
Next the log file for wxLua.

http://www.xs4all.nl/~kholwerd/tmp/logs/

Let me know what i should do to test more,

Klaas

Re: [Wxlua-users] Re: wxLua packaging

[John L. <jla...@gm...>]

On 2/21/06, klaas.holwerda <kho...@xs...> wrote:
> >> If so we might pay less attention to VC6 which is not to good i think.
> > I think MSVC6 is going to be completely 'deprecated' in few years...
> That is what i think too. But at the moment?
> > maybe we could:
> > a) move msvc6 project files in the new build\msvc6 folders
> > b) convert msvc6 project files and add them in the build\msvc7/8 folder=
s
> Good idea.
> >
> > Unfortunately AFAIK MSVC.NET and MSVC2005 use two different formats...
> > I'm going to see if I can add these formats to bakefile.

But, don't they both support converting from dsp files to their sln
files? I use 2005, the free one new and I've also used .NET (a few
years back) and both converted the dsp files just fine. You had to be
careful about deleting the sln files if you edited the dsp files, but
that wasn't a big deal.

> >> I myself get linking errors, etc. i wonder if this is because of VC6
> >> or soemthing else.
> I put the two logs files here.
>
> First i tried to make wxStedit which i downloaded at wxCode. ( I tried
> first CVS but had problems so i downloaded it eventually.)
> It is not clear yet from install.html which one i should get.
> That i tried to build without success.
> Next the log file for wxLua.
>
> http://www.xs4all.nl/~kholwerd/tmp/logs/

I've updated wxStEdit in wxCode's CVS to remove the warnings. I'm
sorry, I've never tried to compile wxWidgets as a DLL so I have no
experience on why you get so many unresolved function errors. Do you
have to cross link libraries to get it to work? Dunno.

John Labenski

[Wxlua-users] Re: wxLua packaging

[Francesco M. <f18...@ya...>]

Hi,

klaas.holwerda ha scritto:
> First i tried to make wxStedit which i downloaded at wxCode. ( I tried 
> first CVS but had problems so i downloaded it eventually.)
> It is not clear yet from install.html which one i should get.
I've added the minimal versions required.
For wxStEdit I used as minimal version to use 1.0.0.1 which is not 
available (yet); I'll try to build wxStEdit and maybe give an hand with 
those warnings.
After that, with a working configure script I think we could make this 
new release of wxStEdit; John, is it okay for you?

Francesco

Re: [Wxlua-users] Re: wxLua packaging

[John L. <jla...@gm...>]

On 2/21/06, k. holwerda <kla...@nl...> wrote:
> wx_object.cpp
> ..\..\..\modules\wxlua/include/wxlstate.h(184) : warning C4251:
> 'm_coroutineStates' : class 'wxArrayLuaState' needs to have
> dll-interface to be used by clients of class 'wxLuaStateRefData'
>         ..\..\..\modules\wxlua/include/wxlstate.h(156) : see declaration
> of 'wxArrayLuaState'
> ..\..\..\modules\wxlua/include/wxlstate.h(190) : warning C4251:
> 's_wxHashMapLuaStateRefData' : class 'wxHashMapLuaStateRefData' needs to
> have dll-interface to be used by clients of class 'wxLuaStateRefData'
>         ..\..\..\modules\wxlua/include/wxlstate.h(159) : see declaration
> of 'wxHashMapLuaStateRefData'
> ..\..\..\modules\wxluadebug/include/wxldebug.h(108) : warning C4275: non
> dll-interface class 'wxLuaDebugDataItemArray' used as base for
> dll-interface class 'wxLuaDebugData'
>         ..\..\..\modules\wxluadebug/include/wxldebug.h(100) : see
> declaration of 'wxLuaDebugDataItemArray'

Fixed.

Regards,
    John Labenski

Re: [Wxlua-users] Re: wxLua packaging

[k. h. <kla...@nl...>]

Hi John,

John Labenski wrote:

>I've updated wxStEdit in wxCode's CVS to remove the warnings. I'm
>sorry, I've never tried to compile wxWidgets as a DLL so I have no
>experience on why you get so many unresolved function errors.
>
i have seen the before in wxArt2D, and in VC6 it is often impossible to 
solve.
( that is why i like the idea of seperating the project files in VC6 and 
VC.NET versions.
Like that we can make them work for what they can work, just diable the 
generation of DLL flavours in VC6 etc.
)
But in higher version it is/can be oke.
I am also not experienced with this, but in wxArt2D there is this dll 
wizard Leo, and i gladly take over his tricks ;-)

> Do you
>have to cross link libraries to get it to work? Dunno.
>  
>
If we can not make it work, we better tell the user, or diable those in 
the project files.

The next change, improves it a bit.

#include "wx/dynarray.h"
WX_DECLARE_OBJARRAY_WITH_DECL( wxLuaState, wxArrayLuaState, class 
WXDLLIMPEXP_WXLUA );

#include "wx/hashmap.h"
WX_DECLARE_VOIDPTR_HASH_MAP_WITH_DECL( wxLuaStateRefData *, 
wxHashMapLuaStateRefData, class WXDLLIMPEXP_WXLUA  );

will check it in this evening,

Klaas

-- 
Unclassified

Re: [Wxlua-users] Re: wxLua packaging

[John L. <jla...@gm...>]

On 2/22/06, k. holwerda <kla...@nl...> wrote:
> If we can not make it work, we better tell the user, or diable those in
> the project files.

Or leave them on with a warning and maybe somebody more knowledgeable
will know how to fix it or at least understand the problem. If we
disable it, nobody can help us.

> The next change, improves it a bit.
>
> #include "wx/dynarray.h"
> WX_DECLARE_OBJARRAY_WITH_DECL( wxLuaState, wxArrayLuaState, class
> WXDLLIMPEXP_WXLUA );
>
> #include "wx/hashmap.h"
> WX_DECLARE_VOIDPTR_HASH_MAP_WITH_DECL( wxLuaStateRefData *,
> wxHashMapLuaStateRefData, class WXDLLIMPEXP_WXLUA  );
>
> will check it in this evening,

Already done.

-John Labenski

[Wxlua-users] Re: wxLua packaging

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> On 2/21/06, klaas.holwerda <kho...@xs...> wrote:
>>>> If so we might pay less attention to VC6 which is not to good i think.
>>> I think MSVC6 is going to be completely 'deprecated' in few years...
>> That is what i think too. But at the moment?
>>> maybe we could:
>>> a) move msvc6 project files in the new build\msvc6 folders
>>> b) convert msvc6 project files and add them in the build\msvc7/8 folders
>> Good idea.
>>> Unfortunately AFAIK MSVC.NET and MSVC2005 use two different formats...
>>> I'm going to see if I can add these formats to bakefile.
> 
> But, don't they both support converting from dsp files to their sln
> files? I use 2005, the free one new and I've also used .NET (a few
> years back) and both converted the dsp files just fine. You had to be
> careful about deleting the sln files if you edited the dsp files, but
> that wasn't a big deal.
yes, they support it but having the SLN file directly is more 
comfortable for the end user, isn't it?

Please let me know if you agree to do this change (build\msvc6 and 
build\msvc8) since I need to know that before completing install.html doc

Francesco

Re: [Wxlua-users] Re: wxLua packaging

[John L. <jla...@gm...>]

On 2/23/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > On 2/21/06, klaas.holwerda <kho...@xs...> wrote:
> >>>> If so we might pay less attention to VC6 which is not to good i thin=
k.
> >>> I think MSVC6 is going to be completely 'deprecated' in few years...
> >> That is what i think too. But at the moment?
> >>> maybe we could:
> >>> a) move msvc6 project files in the new build\msvc6 folders
> >>> b) convert msvc6 project files and add them in the build\msvc7/8 fold=
ers
> >> Good idea.
> >>> Unfortunately AFAIK MSVC.NET and MSVC2005 use two different formats..=
.
> >>> I'm going to see if I can add these formats to bakefile.
> >
> > But, don't they both support converting from dsp files to their sln
> > files? I use 2005, the free one new and I've also used .NET (a few
> > years back) and both converted the dsp files just fine. You had to be
> > careful about deleting the sln files if you edited the dsp files, but
> > that wasn't a big deal.
> yes, they support it but having the SLN file directly is more
> comfortable for the end user, isn't it?
>
> Please let me know if you agree to do this change (build\msvc6 and
> build\msvc8) since I need to know that before completing install.html doc

Well, sure, if it's easy to do, why not? I usually go for the minimal
approach, I got a lot on my plate right now.

John Labenski