wxcode-users — Submission, Questions, Information

Re: [wxCode-users] Cron job: wxDNSSD is pending approval

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

William H. Schultz ha scritto:
> I can see that the folder has been added to the CVS repository (through 
> sourceforge's browse CVS feature), but I can't login to do a CVS 
> checkout with my sourceforge account. 
sorry - we forget to add you to the devel list of wxCode project. Done now.

> I would rather use SVN, 
> personally, but I also can't added the directory to the SVN repository 
> (authorization failed).
> 
> Ideas?
I'll move your new component under wxCode SVN. I really need to add a 
"CVS/SVN repository" radio box in component submission form ;)

Before doing it however:

   1) I'd remove the "wx" prefix from the directory name. I hope this is 
ok for you. Components with the 'wx' prefix in dir name should be avoid.

   2) is wxDNSSD the best name for such component ? It looks a little 
weird for me and, maybe because I'm ignorant, don't say me much about 
what it is. Could it be better to rename it to e.g. wxBonjour?


Francesco

Re: [wxCode-users] Cron job: wxDNSSD is pending approval

[William H. S. <whs...@ce...>]

I can see that the folder has been added to the CVS repository  
(through sourceforge's browse CVS feature), but I can't login to do a  
CVS checkout with my sourceforge account.  I would rather use SVN,  
personally, but I also can't added the directory to the SVN  
repository (authorization failed).

Ideas?


Thanks.

-------------------------------
Hank Schultz
Cedrus Corporation
http://www.cedrus.com/


On Oct 28, 2006, at 11:45 PM, John Labenski wrote:

> Added and approved, give the CVS a hour or so to update. Please read
> the maintainer guide http://wxcode.sourceforge.net/maintguide.php for
> some tips.
>
> -John Labenski
>
>
> On 10/28/06, Francesco Montorsi <fr...@us...> wrote:
>> name: wxDNSSD
>> wxversion: cvs
>> category: networking
>> language: cpp
>> description: This is a set of wrapper classes around Apple's  
>> Bonjour SDK.  This will allow wxWidgets applications to broadcast,  
>> browse, and resolve services.  This has been tested on wxMac and  
>> wxMSW, both in a unicode build.  Additional platforms should be  
>> possible with the code already implemented, though it has not been  
>> tested.
>> location: wxdnssd
>> cdate: 2006-10-27
>> id: 122
>> status: alpha
>> docs: notavailable
>> buildsys:
>> extdep: Apple's Bonjour SDK
>> wiki: enabled
>> wxport: wxmsw,wxmac
>> samples: 0
>> approved: 0
>> author: Hank Schultz
>> version: 1.0
>> maintainerid: 46
>>
>> Maintainer SF username: whschultz
>> Maintainer name: Hank Schultz
>> Maintainer mail address: whs...@ce...
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> wxCode-users mailing list
>> wxC...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users

[wxCode-users] [ wxcode-Bugs-1587257 ] wxplotctrl compilation error

[SourceForge.net <no...@so...>]

Bugs item #1587257, was opened at 2006-10-30 15:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462816&aid=1587257&group_id=51305

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: last released version
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jerk (fantaz)
Assigned to: Nobody/Anonymous (nobody)
Summary: wxplotctrl compilation error

Initial Comment:
in bool wxPlotPrintout::ShowPrintSetupDialog()
are lines
#if !wxCHECK_VERSION(2,7,0)
    printerDialog.GetPrintDialogData().
SetSetupDialog(true);
#endif //!wxCHECK_VERSION(2,7,0)
However, as stated in cmndata.h
SetSetupDialog is alive only when 
WXWIN_COMPATIBILITY_2_4 is defined.
There should be something to foresee that...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462816&aid=1587257&group_id=51305

Re: [wxCode-users] Cron job: wxDNSSD is pending approval

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

Added and approved, give the CVS a hour or so to update. Please read
the maintainer guide http://wxcode.sourceforge.net/maintguide.php for
some tips.

-John Labenski


On 10/28/06, Francesco Montorsi <fr...@us...> wrote:
> name: wxDNSSD
> wxversion: cvs
> category: networking
> language: cpp
> description: This is a set of wrapper classes around Apple's Bonjour SDK.  This will allow wxWidgets applications to broadcast, browse, and resolve services.  This has been tested on wxMac and wxMSW, both in a unicode build.  Additional platforms should be possible with the code already implemented, though it has not been tested.
> location: wxdnssd
> cdate: 2006-10-27
> id: 122
> status: alpha
> docs: notavailable
> buildsys:
> extdep: Apple's Bonjour SDK
> wiki: enabled
> wxport: wxmsw,wxmac
> samples: 0
> approved: 0
> author: Hank Schultz
> version: 1.0
> maintainerid: 46
>
> Maintainer SF username: whschultz
> Maintainer name: Hank Schultz
> Maintainer mail address: whs...@ce...
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>

[wxCode-users] Cron job: wxDNSSD is pending approval

[Francesco M. <fr...@us...>]

name: wxDNSSD
wxversion: cvs
category: networking
language: cpp
description: This is a set of wrapper classes around Apple's Bonjour SDK.  This will allow wxWidgets applications to broadcast, browse, and resolve services.  This has been tested on wxMac and wxMSW, both in a unicode build.  Additional platforms should be possible with the code already implemented, though it has not been tested.
location: wxdnssd
cdate: 2006-10-27
id: 122
status: alpha
docs: notavailable
buildsys: 
extdep: Apple's Bonjour SDK
wiki: enabled
wxport: wxmsw,wxmac
samples: 0
approved: 0
author: Hank Schultz
version: 1.0
maintainerid: 46

Maintainer SF username: whschultz
Maintainer name: Hank Schultz
Maintainer mail address: whs...@ce...

Re: [wxCode-users] bakefile, Makefile.in and install targets

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

On 10/26/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > I applied a much simplier solution, you're still locked into using
> > include/wx as a base path but you can now specify any number of
> > additional extra paths.
> >
> > You merely set a variable in your component's bakefile as shown in the
> > template bakefile: wxCode/build/empty.bkl.template
> >
> >     <!-- Specify an optional extra path to the header files for
> > install-wxheaders
> >          component/include/wx[$(DIRSEP)optional path]
> >          Always include the leading $(DIRSEP) and no trailing one, leave blank
> >          to use the path include/wx to your headers. -->
> >     <set var="COMP_WXHEADERS_EXTRA_INCLUDE_PATH">
> >     </set>
> >
> > and then it's used here wxCode/build/targets.bkl.
> This is a good temporary fix sure. Thanks!
>
> Ok - I repeated it one million times but let me repeat once again;
> bakefile SVN trunk has a much better support for headers and you won't
> need any hack like this.

Someday... there will be a new release of bakefile...

> Just like <sources> there will be an <headers> tag which will recognize
> which are the folders required by header files and will automatically
> install them.

That will be nice, I think I can struggle on with 0.2.0, at least for
now hoping that everything is working.

-John Labenski

Re: [wxCode-users] configure's AC_CONFIG_AUX_DIR uses the wxCode/build path, breaking out of tree builds

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

Hi,

John Labenski ha scritto:
> There is a problem using bakefile and configure for a component when
> it's out of the wxCode tree, eg. a tar.gz source package.
> 
> 
> [john@amd2600 a]$ ../configure
> --prefix=/home/john/cvs/a/wxCode/components/wxstedit/a
> checking for the --enable-debug option... will be automatically detected
> ...
> checking for the --with-wxshared option... will be automatically detected
> configure: error: cannot run /bin/sh build/config.sub
> 
> 
> The problem is that the path to look for config.sub is wrong. In the
> configure generated by acregen.sh you have this
> 
> ac_config_sub="$SHELL $ac_aux_dir/config.sub"
> 
> which means that it looks in
> 
> ac_aux_dir=
> for ac_dir in ../../../build/autoconf build
> $srcdir/../../../build/autoconf build; do
> ...
> 
> What we really want is for it to look into $srcdir/build where you
> should have copied all all appropriate scripts.
> 
> ==============
> 
> Here's where the problem is
> wxCode/build/autoconf/wxcode.m4
> 
> AC_DEFUN([AM_WXCODE_INIT],
>         [
>             AC_PREREQ([2.57])
>             AC_CONFIG_AUX_DIR([../../../build/autoconf build])
>             m4_include(../../../build/autoconf/wxpresets.m4)
>             AC_LANG(C++)
>         ])
> 
> I don't think that having two paths is standard. You can see that only
> the first dir gets prepended with $srcdir which is why you cannot run
> configure out of the wxCode tree.
> 
> I am going to replace the line
> 
>     AC_CONFIG_AUX_DIR([../../../build/autoconf build])
> 
> with just this
> 
>     AC_CONFIG_AUX_DIR(build)
> 
> which means that you have to have all the appropriate scripts in your
> build dir which is what you'd need to build out of the tree anyway.
Seems right to me. Sincerely I don't remember why I did put the 
../../../build/autoconf directory in AC_CONFIG_AUX_DIR macro but indeed 
it looks like an incorrect usage of that macro.

I'll test some of my components to see if I find any problem/issue just 
to be sure.

Thanks!
Francesco

Re: [wxCode-users] bakefile, Makefile.in and install targets

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

John Labenski ha scritto:
> I applied a much simplier solution, you're still locked into using
> include/wx as a base path but you can now specify any number of
> additional extra paths.
> 
> You merely set a variable in your component's bakefile as shown in the
> template bakefile: wxCode/build/empty.bkl.template
> 
>     <!-- Specify an optional extra path to the header files for
> install-wxheaders
>          component/include/wx[$(DIRSEP)optional path]
>          Always include the leading $(DIRSEP) and no trailing one, leave blank
>          to use the path include/wx to your headers. -->
>     <set var="COMP_WXHEADERS_EXTRA_INCLUDE_PATH">
>     </set>
> 
> and then it's used here wxCode/build/targets.bkl.
This is a good temporary fix sure. Thanks!

Ok - I repeated it one million times but let me repeat once again; 
bakefile SVN trunk has a much better support for headers and you won't 
need any hack like this.

Just like <sources> there will be an <headers> tag which will recognize 
which are the folders required by header files and will automatically 
install them.

Francesco

Re: [wxCode-users] configure problems (Re: bakefile does create configure?)

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

On 10/26/06, Francesco Montorsi <f18...@ya...> wrote:
...
> Are there other problems in configure-generated script?

Just to answer this one, no... I guess not. See the other emails, I
tried to give them new titles for each little problem and have
committed some changes that I think solve everything.

I will go through the bakefile/autoconf guide on wxCode and add some
little things that I've learned.

Currently, I have working static, shared, in/out of wxCode tree builds
working in linux using configure for wxStEdit.

Let me know if you can think of better ways to implement the changes I
wrote about in the other emails.
     John Labenski

[wxCode-users] configure problems (Re: bakefile does create configure?)

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

Hi,
   sorry for not following closely the discussion. I'm really spending 
all my free time fixing stuff in wxWidgets right now as wx2.8 is really 
really near and I'd like to stuff all the things I always wanted from 
wxWidgets before that.


klaas.holwerda ha scritto:
> I understand that you keep things nicely seperate, it will works fine.
> The thing is that users will not do this. Like me ;-) I just make and 
> make install, because that is most likely to work normally.
> I think Francesco knows how wx-config works with several installed 
> wxWidgets flavors.
yes, it's a bit of a trouble but the M4 macros I've created should make 
it much easier to create fully configurable wx-based programs.

> I was once explained by the Ron on the dev list.
> All looks unavailable so i can show it from the archives, but in my own 
> archive the title of the thread is "About wx_unix.bkl", and it
> explains it well.
yeah; I remember that thread ;)
I'm going to try to ask for better wxpresets right after this mail on 
wx-dev; if I could manage to get all my "wxpresets hacks" directly in 
wxpresets before wx2.8 it would be just fantastic!


> In short it is possible to detect with wx-config  if a certain flavour 
> of wxWidgets is available ( like debug-unicode-release ).
sure, and wxCode configure scripts do that and also show a nice summary 
at the end of the run summing up all settings detected/chosen by the user.

> I assumed that all that trickery is somehow part of the bakefile 
> generated makefiles.
> And when i run configure, i get the impression that it is.  ( like auto 
> detect and several switches ), but it seems it does not work correctly.
> Francesco, how good is this already?
I've changed the name of the thread because I had problems to understand 
exactly what are the problems you found in configure script.

Skimming the mails I've noticed you and John hit the include/wx/*.h 
problem. That's a know problem fixed in bakefile SVN trunk.

I'm also aware that it's difficult to create configure script which can 
be used for the trick:

   mkdir mybuild && cd mybuild && ../configure etc etc

(it's not impossible just tricky).

I'm aware of those two problems and there are relative patches in 
bakefile tracker but the problem is the usual one - bakefile support and 
patch revision is slow.

Are there other problems in configure-generated script?

Francesco

Re: [wxCode-users] Cron job: wxRubberBand is pending approval

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

It's been approved and should be available to you in a few hours.

Please see the template to get an idea of a prefered dir structure and
some bits and pieces that may be interesting as well.

http://wxcode.sourceforge.net/template.php
http://wxcode.cvs.sourceforge.net/wxcode/wxCode/template/

Regards,
    John Labenski


On 10/25/06, Francesco Montorsi <fr...@us...> wrote:
> name: wxRubberBand
> wxversion: 2.6
> category: graphics
> language: cpp
> description: wxRubberBand is a class used for drawing a selection box on a drawing area. This is intended for developers who want to include graphical selection availabilities in there programs.
> location: wxrubberband
> cdate: 2006-10-20
> id: 121
> status: beta
> docs: doxygen
> buildsys: cmake
> extdep: none
> wiki: disabled
> wxport: all
> samples: 1
> approved: 0
> author: Lucien Schreiber
> version: 1.0
> maintainerid: 45
>
> Maintainer SF username: swiss_kinkajou
> Maintainer name: kinkajou
> Maintainer mail address: luc...@gm...
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>

[wxCode-users] configure's AC_CONFIG_AUX_DIR uses the wxCode/build path, breaking out of tree builds

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

There is a problem using bakefile and configure for a component when
it's out of the wxCode tree, eg. a tar.gz source package.


[john@amd2600 a]$ ../configure
--prefix=/home/john/cvs/a/wxCode/components/wxstedit/a
checking for the --enable-debug option... will be automatically detected
...
checking for the --with-wxshared option... will be automatically detected
configure: error: cannot run /bin/sh build/config.sub


The problem is that the path to look for config.sub is wrong. In the
configure generated by acregen.sh you have this

ac_config_sub="$SHELL $ac_aux_dir/config.sub"

which means that it looks in

ac_aux_dir=
for ac_dir in ../../../build/autoconf build
$srcdir/../../../build/autoconf build; do
...

What we really want is for it to look into $srcdir/build where you
should have copied all all appropriate scripts.

==============

Here's where the problem is
wxCode/build/autoconf/wxcode.m4

AC_DEFUN([AM_WXCODE_INIT],
        [
            AC_PREREQ([2.57])
            AC_CONFIG_AUX_DIR([../../../build/autoconf build])
            m4_include(../../../build/autoconf/wxpresets.m4)
            AC_LANG(C++)
        ])

I don't think that having two paths is standard. You can see that only
the first dir gets prepended with $srcdir which is why you cannot run
configure out of the wxCode tree.

I am going to replace the line

    AC_CONFIG_AUX_DIR([../../../build/autoconf build])

with just this

    AC_CONFIG_AUX_DIR(build)

which means that you have to have all the appropriate scripts in your
build dir which is what you'd need to build out of the tree anyway.

Regards,
    John Labenski

[wxCode-users] Cron job: wxRubberBand is pending approval

[Francesco M. <fr...@us...>]

name: wxRubberBand
wxversion: 2.6
category: graphics
language: cpp
description: wxRubberBand is a class used for drawing a selection box on a drawing area. This is intended for developers who want to include graphical selection availabilities in there programs. 
location: wxrubberband
cdate: 2006-10-20
id: 121
status: beta
docs: doxygen
buildsys: cmake
extdep: none
wiki: disabled
wxport: all
samples: 1
approved: 0
author: Lucien Schreiber
version: 1.0
maintainerid: 45

Maintainer SF username: swiss_kinkajou
Maintainer name: kinkajou
Maintainer mail address: luc...@gm...

Re: [wxCode-users] bakefile, Makefile.in and install targets

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

I applied a much simplier solution, you're still locked into using
include/wx as a base path but you can now specify any number of
additional extra paths.

You merely set a variable in your component's bakefile as shown in the
template bakefile: wxCode/build/empty.bkl.template

    <!-- Specify an optional extra path to the header files for
install-wxheaders
         component/include/wx[$(DIRSEP)optional path]
         Always include the leading $(DIRSEP) and no trailing one, leave blank
         to use the path include/wx to your headers. -->
    <set var="COMP_WXHEADERS_EXTRA_INCLUDE_PATH">
    </set>

and then it's used here wxCode/build/targets.bkl.

Hope this helps,
     John Labenski



On 10/25/06, John Labenski <jla...@gm...> wrote:
> In wxCode/build/bakefile/targets.bkl we have, which is similar as
> COMP_WANT_UNINSTALL_WXHEADERS_TARGET.
>
>             <!-- "make install-wxheaders": -->
>             <if cond="COMP_WANT_INSTALL_WXHEADERS_TARGET=='1'">
>               <data-files-tg id="install-wxheaders">
>
> <files>$(COMP_BASEPATH)$(DIRSEP)include$(DIRSEP)wx$(DIRSEP)*.h</files>
>                   <if cond="TARGETING_WIN32=='1'">
>
> <install-to>$(WX_DIR)$(DIRSEP)include$(DIRSEP)wx</install-to>
>
>                       <!-- little hack over "data-files-tg" which is
> truly defined only on unix -->
>                       <set var="__copy_cmd" eval="0">
>                           mkdir $(__dstdir)
>                           cd $(__srcdir)
>                           copy /Y $(__files) $(__dstdir)
>                       </set>
>                       <dependency-of>install</dependency-of>
>                       <command>$(__copy_cmd)</command>
>                   </if>
>                   <if cond="TARGETING_WIN32=='0'">
>                       <install-to>$(INCLUDEDIR)/wx</install-to>
>                   </if>
>               </data-files-tg>
>
> ============================
>
> BUT! If you have your includes as
> wxCode/components/wxstedit/include/wx/stedit/*.h this doesn't work. I
> figured that by adding "stedit" to the include path I'd avoid any
> problems with name clashes.
>
> In your user bakefile you have, optionally
>
> <set var="COMP_INCLUDE_PATH" overwrite="0">
>      include$(DIRSEP)wx$(DIRSEP)/stedit
> </set>
>
>
> and in wxCode/build/bakefile/targets.bkl
>
>
> <set var="COMP_INCLUDE_PATH" overwrite="0">
>      include$(DIRSEP)wx
> </set>
>
> and adjust the install and uninstall targets to use it
>
>             <!-- "make install-wxheaders": -->
>             <if cond="COMP_WANT_INSTALL_WXHEADERS_TARGET=='1'">
>               <data-files-tg id="install-wxheaders">
>
> <files>$(COMP_BASEPATH)$(DIRSEP)$(COMP_INCLUDE_PATH)$(DIRSEP)*.h</files>
>                   <if cond="TARGETING_WIN32=='1'">
>
> <install-to>$(WX_DIR)$(DIRSEP)$(COMP_INCLUDE_PATH)</install-to>
>
>                       <!-- little hack over "data-files-tg" which is
> truly defined only on unix -->
>                       <set var="__copy_cmd" eval="0">
>                           mkdir $(__dstdir)
>                           cd $(__srcdir)
>                           copy /Y $(__files) $(__dstdir)
>                       </set>
>                       <dependency-of>install</dependency-of>
>                       <command>$(__copy_cmd)</command>
>                   </if>
>                   <if cond="TARGETING_WIN32=='0'">
>                       <install-to>$(INCLUDEDIR)/wx</install-to>   <=== HERE!
>                   </if>
>               </data-files-tg>
>
> ============================
>
> How to make the <install-to> item work? It doesn't want the "include"
> part of the path since it already has it from wxWidgets/include.
>
> Maybe just have the user only specify "wx/stedit" and assume
> everything is in "include" as in "include/wx/stedit"? Or will we run
> into similar problems with some other "nonstandard" component like
> mine?
>
> Any ideas?
>     John Labenski
>

[wxCode-users] bakefile does create configure?

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

Hi,

I understand that you keep things nicely seperate, it will works fine.
The thing is that users will not do this. Like me ;-) I just make and 
make install, because that is most likely to work normally.
I think Francesco knows how wx-config works with several installed 
wxWidgets flavors.
I was once explained by the Ron on the dev list.
All looks unavailable so i can show it from the archives, but in my own 
archive the title of the thread is "About wx_unix.bkl", and it
explains it well.
In short it is possible to detect with wx-config  if a certain flavour 
of wxWidgets is available ( like debug-unicode-release ).
I assumed that all that trickery is somehow part of the bakefile 
generated makefiles.
And when i run configure, i get the impression that it is.  ( like auto 
detect and several switches ), but it seems it does not work correctly.
Francesco, how good is this already?
 
Klaas

John Labenski wrote:
>
> ------
>
> Next up, get make install to work for wxStEdit. I see how to hack
> Makefile.in to do it, but I would prefer a bakefile solution.
>
>
>   

[wxCode-users] bakefile, Makefile.in and install targets

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

In wxCode/build/bakefile/targets.bkl we have, which is similar as
COMP_WANT_UNINSTALL_WXHEADERS_TARGET.

            <!-- "make install-wxheaders": -->
            <if cond="COMP_WANT_INSTALL_WXHEADERS_TARGET=='1'">
              <data-files-tg id="install-wxheaders">

<files>$(COMP_BASEPATH)$(DIRSEP)include$(DIRSEP)wx$(DIRSEP)*.h</files>
                  <if cond="TARGETING_WIN32=='1'">

<install-to>$(WX_DIR)$(DIRSEP)include$(DIRSEP)wx</install-to>

                      <!-- little hack over "data-files-tg" which is
truly defined only on unix -->
                      <set var="__copy_cmd" eval="0">
                          mkdir $(__dstdir)
                          cd $(__srcdir)
                          copy /Y $(__files) $(__dstdir)
                      </set>
                      <dependency-of>install</dependency-of>
                      <command>$(__copy_cmd)</command>
                  </if>
                  <if cond="TARGETING_WIN32=='0'">
                      <install-to>$(INCLUDEDIR)/wx</install-to>
                  </if>
              </data-files-tg>

============================

BUT! If you have your includes as
wxCode/components/wxstedit/include/wx/stedit/*.h this doesn't work. I
figured that by adding "stedit" to the include path I'd avoid any
problems with name clashes.

In your user bakefile you have, optionally

<set var="COMP_INCLUDE_PATH" overwrite="0">
     include$(DIRSEP)wx$(DIRSEP)/stedit
</set>


and in wxCode/build/bakefile/targets.bkl


<set var="COMP_INCLUDE_PATH" overwrite="0">
     include$(DIRSEP)wx
</set>

and adjust the install and uninstall targets to use it

            <!-- "make install-wxheaders": -->
            <if cond="COMP_WANT_INSTALL_WXHEADERS_TARGET=='1'">
              <data-files-tg id="install-wxheaders">

<files>$(COMP_BASEPATH)$(DIRSEP)$(COMP_INCLUDE_PATH)$(DIRSEP)*.h</files>
                  <if cond="TARGETING_WIN32=='1'">

<install-to>$(WX_DIR)$(DIRSEP)$(COMP_INCLUDE_PATH)</install-to>

                      <!-- little hack over "data-files-tg" which is
truly defined only on unix -->
                      <set var="__copy_cmd" eval="0">
                          mkdir $(__dstdir)
                          cd $(__srcdir)
                          copy /Y $(__files) $(__dstdir)
                      </set>
                      <dependency-of>install</dependency-of>
                      <command>$(__copy_cmd)</command>
                  </if>
                  <if cond="TARGETING_WIN32=='0'">
                      <install-to>$(INCLUDEDIR)/wx</install-to>   <=== HERE!
                  </if>
              </data-files-tg>

============================

How to make the <install-to> item work? It doesn't want the "include"
part of the path since it already has it from wxWidgets/include.

Maybe just have the user only specify "wx/stedit" and assume
everything is in "include" as in "include/wx/stedit"? Or will we run
into similar problems with some other "nonstandard" component like
mine?

Any ideas?
    John Labenski

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

On 10/25/06, Klaas Holwerda <db...@nl...> wrote:
> John Labenski wrote:
> >
> > Anyway, with this simple fix you can use static libs if you like. If I
> > understand correctly, aren't shared libs faster to compile stuff
> > locally since the linker stage takes a little less time? Anyway,
> > that's the reason why I make shared libs if I'm only going to use the
> > program on my own machine, if this is wrong I'd like to know.
>
> I don't know, i just use static to not have dependencies for users of my software. But i can imagine that its quicker to
> link that way.

Thats what I thought too.

> So in the end the problem which is still strange, is that in shared mode the wxstedit sample gave a asserts.
> I think this is because the same libraries are linked several times.

Ok, I see the problem, I was double linking core and base, fixed in
wxStEdit CVS.

> All other smaller problems are configure like issues, like how to get static build when both static and shared wxWidgets
> are available. Very likeley wx-config is not used correctly in the configure scripts.

This is what I do, I set the path to the wx-config I want, create a
new dir in wxStEdit, run ../configure --prefix=new/dir, and that way
you can have two separate build at the same time.

In wxWidgets I do the same, create a dir wxWidgets/config_gtk2_debug
and config_gtk2_static and run ../configure
--prefix=/path/to/wxWidgets/config_gtk2_XXX ... so that I have two
builds at once. I never bother to install wxWidgets since wx-config
finds the includes and the libs properly if you do the above.

------

Next up, get make install to work for wxStEdit. I see how to hack
Makefile.in to do it, but I would prefer a bakefile solution.

Regards,
    John Labenski

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

[Klaas H. <db...@nl...>]

John Labenski wrote:

> 
> Anyway, with this simple fix you can use static libs if you like. If I
> understand correctly, aren't shared libs faster to compile stuff
> locally since the linker stage takes a little less time? Anyway,
> that's the reason why I make shared libs if I'm only going to use the
> program on my own machine, if this is wrong I'd like to know.

I don't know, i just use static to not have dependencies for users of my software. But i can imagine that its quicker to 
link that way.

So in the end the problem which is still strange, is that in shared mode the wxstedit sample gave a asserts.
I think this is because the same libraries are linked several times.

All other smaller problems are configure like issues, like how to get static build when both static and shared wxWidgets 
are available. Very likeley wx-config is not used correctly in the configure scripts.

Klaas


-- 
Unclassified

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

Sorry about the delay, you're right that the problem is the linking
order. I got tyhe official wxWidgets 2.6.3 compiled everything as
static release libs and I get the same errors, not linking to
wxNumberEntryDialog for example.

The problem is that the configure generated Makefile puts the stedit
lib after the WX_LIBS and this is wrong. Here is the right way to do
it in the generated Makefile,

./samples/stedit/wxstedit$(EXEEXT): $(WXSTEDIT_OBJECTS)
$(__wxstedit___win32rc) $(__stedit_lib___depname)
        $(CXX) -o $@ $(WXSTEDIT_OBJECTS) -L./lib $(LDFLAGS)   -L./lib
$(LDFLAGS_GUI)
-lwx_$(WX_PORT_WITHVERSION)$(WXLIBPOSTFIX)_stedit-$(WX_VERSION_MAJOR).$(WX_VERSION_MINOR)
$(WX_LIBS)

These two libs have been swapped so WX_LIBS comes last.
-lwx_$(WX_PORT_WITHVERSION)$(WXLIBPOSTFIX)_stedit-$(WX_VERSION_MAJOR).$(WX_VERSION_MINOR)
$(WX_LIBS)

I'm trying to figure out where this comes from, but so far I cannot
tell where to fix it just yet. I see that the problem is also in
Makefile.in so this means that bakefile is creating the problem, I'll
keep looking. As a temp fix I'll commit Makefile.in with the order
reversed.

Anyway, with this simple fix you can use static libs if you like. If I
understand correctly, aren't shared libs faster to compile stuff
locally since the linker stage takes a little less time? Anyway,
that's the reason why I make shared libs if I'm only going to use the
program on my own machine, if this is wrong I'd like to know.

Once I get the static libs worked out I'll try it with wxLua. I did
get wxLua to work nicely last night, but I had to specify everything
for it to find wxStEdit, see wxLua's configure --help.
configure ... --with-wxstedit-prefix=PATH  --with-wxstedit-lib=NAME

Regards,
    John Labenski

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

I  see this was actually right, since there are only non wxwidgest and 
wxstedit libs in this list.
So to conclude to make it link in static mode the order must be:

g++ -o samples/stedit/wxstedit 
wxstedit_wxstedit.o  -L./lib    -L./lib    -L/usr/local/lib -pthread  
-lwx_gtk2d_stedit-2.6 AND the rest

Klaas



klaas.holwerda wrote:
> [klaas@localhost wxstedit]$ ldd samples/stedit/wxstedit         
> linux-gate.so.1 =>  (0x0027a000)         libgtk-x11-2.0.so.0 => 
> /usr/lib/libgtk-x11-2.0.so.0 (0x0482b000)         libgdk-x11-2.0.so.0 => 
> /usr/lib/libgdk-x11-2.0.so.0 (0x0479f000)         libatk-1.0.so.0 => 
> /usr/lib/libatk-1.0.so.0 (0x04781000)
>         libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 
> (0x046f2000)
>         libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x04736000)
>         libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00232000)
>         libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00273000)
>    

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

So now the static:

I reinstalled wxWidgets static.
And configure of wxstedit gives me this.

----------------------------------------------------------------
  Configuration for wxstedit 1.2.3 successfully completed.
  Summary of main configuration settings for wxstedit:
  - DEBUG build
  - ANSI mode
  - STATIC mode

  The wxWidgets build which will be used by wxstedit 1.2.3
  has the following settings:
  - DEBUG build
  - ANSI mode
  - STATIC mode
  - VERSION: 2.6.3
  - PORT: gtk (with GTK+ 2.x)

  Now, just run make.
 ----------------------------------------------------------------

BUT this one gives me the linking errors.

[klaas@localhost wxstedit]$ make
g++ -o samples/stedit/wxstedit wxstedit_wxstedit.o  -L./lib    
-L./lib    -L/usr/local/lib -pthread   /usr/local/lib/libwx_based-2.6.a 
/usr/local/lib/libwx_gtk2d_core-2.6.a 
/usr/local/lib/libwx_gtk2d_adv-2.6.a 
/usr/local/lib/libwx_gtk2d_html-2.6.a 
/usr/local/lib/libwx_gtk2d_stc-2.6.a 
/usr/local/lib/libwx_gtk2d_core-2.6.a /usr/local/lib/libwx_based-2.6.a 
-pthread -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lpng -ljpeg -ltiff -lz -ldl -lm  -lwx_gtk2d_stedit-2.6


BUT changing it to this makes and link and run wxstedit without problem.
To bad ldd show me not static libaries linked in????

[klaas@localhost wxstedit]$   g++ -o samples/stedit/wxstedit 
wxstedit_wxstedit.o  -L./lib    -L./lib    -L/usr/local/lib -pthread  
-lwx_gtk2d_stedit-2.6 /usr/local/lib/libwx_gtk2d_adv-2.6.a 
/usr/local/lib/libwx_gtk2d_html-2.6.a 
/usr/local/lib/libwx_gtk2d_stc-2.6.a 
/usr/local/lib/libwx_gtk2d_core-2.6.a /usr/local/lib/libwx_based-2.6.a  
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lpng -ljpeg -ltiff -lz -ldl -lm
[klaas@localhost wxstedit]$


[klaas@localhost wxstedit]$ ldd samples/stedit/wxstedit         
linux-gate.so.1 =>  (0x0027a000)         libgtk-x11-2.0.so.0 => 
/usr/lib/libgtk-x11-2.0.so.0 (0x0482b000)         libgdk-x11-2.0.so.0 => 
/usr/lib/libgdk-x11-2.0.so.0 (0x0479f000)         libatk-1.0.so.0 => 
/usr/lib/libatk-1.0.so.0 (0x04781000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 
(0x046f2000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x04736000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00232000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00273000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00563000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0454c000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x001ce000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00a27000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00dd6000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0020e000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x00a80000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00c6a000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c64000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x045e0000)
        libm.so.6 => /lib/libm.so.6 (0x00c3d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00200000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00dc0000)
        libc.so.6 => /lib/libc.so.6 (0x00b08000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00c7f000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 
(0x04776000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x04b56000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00171000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00d8b000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x001b0000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x046e8000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x001d3000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x001bb000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x001c7000)
        /lib/ld-linux.so.2 (0x0027b000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00d7e000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00d83000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x0470c000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00101000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x00d9d000)
[klaas@localhost wxstedit]$



klaas.holwerda wrote:
> Hi John,
>   

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

Hi John,

So finally i decide to build wxWidgets in shared mode, and see what 
wxstedit did with that.

- it compile and linked, but the samples does not run properly.

[klaas@localhost stedit]$ ldd ./wxstedit
        linux-gate.so.1 =>  (0x0027a000)
        libwx_based-2.6.so.0 => /usr/local/lib/libwx_based-2.6.so.0 
(0x00785000)
        libwx_gtk2d_core-2.6.so.0 => 
/usr/local/lib/libwx_gtk2d_core-2.6.so.0 (0x00296000)
        libwx_gtk2d_adv-2.6.so.0 => 
/usr/local/lib/libwx_gtk2d_adv-2.6.so.0 (0x0095f000)
        libwx_gtk2d_html-2.6.so.0 => 
/usr/local/lib/libwx_gtk2d_html-2.6.so.0 (0x0011f000)
        libsteditd.so.0 => /usr/local/lib/libsteditd.so.0 (0x00a17000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x045e0000)
        libm.so.6 => /lib/libm.so.6 (0x00c3d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00200000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00dc0000)
        libc.so.6 => /lib/libc.so.6 (0x005c4000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00c6a000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c64000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0482b000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x0479f000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x04781000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 
(0x046f2000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x04736000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00232000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00273000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00111000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0454c000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x001ce000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00116000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00dd6000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0020e000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x006f7000)
        /lib/ld-linux.so.2 (0x0027b000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 
(0x04776000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00c7f000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x04b56000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x008be000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00d8b000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x001bc000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x046e8000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x001d3000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x001d7000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x001c7000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x0470c000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00dfe000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00d7e000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00d83000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x00d9d000)
[klaas@localhost stedit]$





[klaas@localhost stedit]$ ./wxstedit
21:12:27: Debug: ./src/common/object.cpp(242): assert 
"sm_classTable->Get(m_className) == NULL" failed: Class 
"wxStyledTextCtrl" already in RTTI table - have you used 
IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?

Call stack:
[05] wxStackWalker::Walk(unsigned int)
[06] 0x0030bf4a
[07] 0x0030c156
[08] wxOnAssert(char const*, int, char const*, char const*)
[09] wxAssert(int, char const*, int, char const*, char const*)
[10] wxClassInfo::Register()
[11] wxClassInfo::wxClassInfo(char const*, wxClassInfo const*, 
wxClassInfo const*, int, wxObject* (*)())
[12] 0x0807e196
[13] 0x0807e221

./src/common/object.cpp(242): assert "sm_classTable->Get(m_className) == 
NULL" failed: Class "wxStyledTextCtrl" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file 
twice)?

Call stack:
[05] wxStackWalker::Walk(unsigned int)
[06] 0x0030bf4a
[07] 0x0030c156
[08] wxOnAssert(char const*, int, char const*, char const*)
[09] wxAssert(int, char const*, int, char const*, char const*)
[10] wxClassInfo::Register()
[11] wxClassInfo::wxClassInfo(char const*, wxClassInfo const*, 
wxClassInfo const*, int, wxObject* (*)())
[12] 0x0807e196
[13] 0x0807e221

Trace/breakpoint trap
[klaas@localhost stedit]$


====================================
- I can not install it, so i did that

[klaas@localhost wxstedit]$ make install by hand and then wxLua was fine 
too.

/usr/bin/install -c -d /usr/local/include/wx
(cd . ; /usr/bin/install -c -m 644  ./include/wx/*.h /usr/local/include/wx)
/usr/bin/install: cannot stat `./include/wx/*.h': No such file or directory
make: *** [install-wxheaders] Error 1
[klaas@localhost wxstedit]$

======================================
Next i wanted to try the static mode again, but configure does not want 
to understand the options, it still chooses shared wxWidgets,
but itself will be in static mode:

 ./configure --enable-debug --enable-std_iostreams --disable-shared 
--with-static
 ----------------------------------------------------------------
  Configuration for wxstedit 1.2.3 successfully completed.
  Summary of main configuration settings for wxstedit:
  - DEBUG build
  - ANSI mode
  - STATIC mode

  The wxWidgets build which will be used by wxstedit 1.2.3
  has the following settings:
  - DEBUG build
  - ANSI mode
  - SHARED mode
  - VERSION: 2.6.3
  - PORT: gtk (with GTK+ 2.x)

  Now, just run make.
 ----------------------------------------------------------------

Now installing wxWidgest static again, and later on will see if i can 
repaet the problem i had with the static builds of wxstedit

Klaas

Klaas Holwerda wrote:
> John Labenski wrote:
>   

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

[Klaas H. <db...@nl...>]

John Labenski wrote:
> On 10/23/06, klaas.holwerda <kho...@xs...> wrote:
> 
>>Hi John,
>>
>>I did the following, to see if the latest produced
>>libwx_gtk2d_stedit-2.6.a might work with wxLua:
> 
> 
> Ok, well first things first, I assume that you can now sucessfully
> compile, link, and run wxstedit, the sample in wxCode's wxstedit? How
> did you fix the problems with not finding the symbols for wxSpinCtrl
> you wrote about before?

No i can not!
I suspected that the problem was only in the sample, and since i already did see the library compiled, i just used it in 
wxLua as is. And installed the library and includes by hand into /usr/local/.
( I could not run make install, because it first wants to make the sample again. )
I think wxSpinCtrl linking problems is somehow in the wxstedit sample only.
Else how can it be oke in wxLua.

> 
> Ok, you're mixing a very old wxLua with the new wxStEdit. Either use
> CVS for both or use wxStEdit 1.2.3 and one of the wxLua snapshots.

But i updated wxLua from CVS first, its brand new. I will remove the whole directory this evening, and checkout again, 
but i am almost sure i have the latest.

> 
> http://wxlua.sourceforge.net/download/
> 
> there is an #ifdef in wxLuaEdit for a change from using a wxlistbox to
> a wxtreectrl to display the opened files in wxstedit.

So very likely that is the problem, and if i solve that this evening. wxLua will compile and link fine, and wxStedit its 
sample will still not link.
Maybe the detection of the wxstedit version is wrong for me, but that easy enough  to find.

The problem is still in the wxstedit sample, and i wonder that it is maybe compiled in non debug while the library is in 
debug. Or else library order.
I will check your old makefile in the samples/stedit directory, if they do compile and link, the problem is in the 
bakefile generated makefiles.

Klaas




-- 
Unclassified

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

On 10/23/06, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>
> I did the following, to see if the latest produced
> libwx_gtk2d_stedit-2.6.a might work with wxLua:

Ok, well first things first, I assume that you can now sucessfully
compile, link, and run wxstedit, the sample in wxCode's wxstedit? How
did you fix the problems with not finding the symbols for wxSpinCtrl
you wrote about before?

> cd /usr/local/lib
> cp libwx_gtk2d_stedit-2.6.a libstedit.a

Yeah... well... this should be documented or better yet fixed, but I
just copy it for now.

> Then i cleaned wxLua ( make clean), and next compiled again. I did
> configure, but i have they idea wxLua is still looking for libstedit.a
> and not libwx_gtk2d_stedit-2.6.a. Same for the include files, which are
> in /usr/local/wx/stedit, and not in /usr/local/wx-2.6??
> I also copied the include files to the same
> /usr/local/include/wx/stedit, if they are not here there is complains,
> so somehow it finds these files, although i don't see
> -I/usr/local/include/wx and only -I/usr/local/include/wx-2.6??

Ok, I haven't tried to install anything using configure, I'll try it
out tonight, I think that we can add a configure option to specify
where the wxstedit includes are.

> So i thought this should work, as it did yesterday with the old
> wxstedit, or at least give the same linking errors.
>
> This is what i get, much better, not yet perfect. Something changed
> with  wxSTEditorFrame::UpdateFileListBox() ?
> If you can make sence of this wxSTEditorFrame::UpdateFileListBox(), i
> think we can then conclude that there something  with the sample linking
> in wxstedit, and not so much  with the library itself because it works
> almost for wxLua in the latest wxstedit  CVS.

Ok, you're mixing a very old wxLua with the new wxStEdit. Either use
CVS for both or use wxStEdit 1.2.3 and one of the wxLua snapshots.

http://wxlua.sourceforge.net/download/

there is an #ifdef in wxLuaEdit for a change from using a wxlistbox to
a wxtreectrl to display the opened files in wxstedit.

Hope this helps,
    John Labenski

Re: [wxCode-users] Bakefile libs in configure was Re: does wxstedit compile with 2.6.3

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

Hi John,

I did the following, to see if the latest produced 
libwx_gtk2d_stedit-2.6.a might work with wxLua:

cd /usr/local/lib
cp libwx_gtk2d_stedit-2.6.a libstedit.a

Then i cleaned wxLua ( make clean), and next compiled again. I did 
configure, but i have they idea wxLua is still looking for libstedit.a 
and not libwx_gtk2d_stedit-2.6.a. Same for the include files, which are 
in /usr/local/wx/stedit, and not in /usr/local/wx-2.6??
I also copied the include files to the same 
/usr/local/include/wx/stedit, if they are not here there is complains, 
so somehow it finds these files, although i don't see 
-I/usr/local/include/wx and only -I/usr/local/include/wx-2.6??

So i thought this should work, as it did yesterday with the old 
wxstedit, or at least give the same linking errors.

This is what i get, much better, not yet perfect. Something changed 
with  wxSTEditorFrame::UpdateFileListBox() ?
If you can make sence of this wxSTEditorFrame::UpdateFileListBox(), i 
think we can then conclude that there something  with the sample linking 
in wxstedit, and not so much  with the library itself because it works 
almost for wxLua in the latest wxstedit  CVS.

Klaas.

[klaas@localhost wxLua]$ make
(cd ./modules/ && make )
make[1]: Entering directory `/home/klaas/soft/wxLua/modules'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/klaas/soft/wxLua/modules'
(cd ./apps/ && make )
make[1]: Entering directory `/home/klaas/soft/wxLua/apps'
g++ -o ../bin/wxlua app_wxlua_wxlua.o app_wxlua_lconsole.o   -L../lib   
-lwxlua_gtk2d_wxlua-2.6 -lwxlua_gtk2d_wxbindstc-2.6 
-lwxlua_gtk2d_wxbind-2.6 -lwxlua_gtk2d_wxluasocket-2.6 
-lwxlua_gtk2d_wxluadebug-2.6 -lwxlua_gtk2d_lua-2.6 -lstedit 
-L/usr/local/lib -pthread   /usr/local/lib/libwx_gtk2d_stc-2.6.a 
/usr/local/lib/libwx_gtk2d_xrc-2.6.a 
/usr/local/lib/libwx_gtk2d_html-2.6.a 
/usr/local/lib/libwx_gtk2d_adv-2.6.a 
/usr/local/lib/libwx_based_net-2.6.a 
/usr/local/lib/libwx_based_xml-2.6.a 
/usr/local/lib/libwx_gtk2d_core-2.6.a /usr/local/lib/libwx_based-2.6.a 
-lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lpng -ljpeg -ltiff -lz -ldl -lm
.././bk-deps g++ -c -o app_wxluaedit_wxledit.o -I../modules -I./.. 
-I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.6 
-I/usr/local/include/wx-2.6 -D__WXDEBUG__ -D__WXGTK__ 
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA    -I/include  -g3 
-O0 -Wall -Wundef -Wno-ctor-dtor-privacy ../apps/wxluaedit/src/wxledit.cpp
.././bk-deps g++ -c -o app_wxluaedit_wxluaedit.o -I../modules -I./.. 
-I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.6 
-I/usr/local/include/wx-2.6 -D__WXDEBUG__ -D__WXGTK__ 
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA    -I/include  -g3 
-O0 -Wall -Wundef -Wno-ctor-dtor-privacy ../apps/wxluaedit/src/wxluaedit.cpp
g++ -o ../bin/wxluaedit app_wxluaedit_wxledit.o 
app_wxluaedit_wxluaedit.o   -L../lib   -lwxlua_gtk2d_wxlua-2.6 
-lwxlua_gtk2d_wxbindstc-2.6 -lwxlua_gtk2d_wxbind-2.6 
-lwxlua_gtk2d_wxluasocket-2.6 -lwxlua_gtk2d_wxluadebug-2.6 
-lwxlua_gtk2d_lua-2.6 -lstedit -lstedit -L/usr/local/lib -pthread   
/usr/local/lib/libwx_gtk2d_stc-2.6.a 
/usr/local/lib/libwx_gtk2d_xrc-2.6.a 
/usr/local/lib/libwx_gtk2d_html-2.6.a 
/usr/local/lib/libwx_gtk2d_adv-2.6.a 
/usr/local/lib/libwx_based_net-2.6.a 
/usr/local/lib/libwx_based_xml-2.6.a 
/usr/local/lib/libwx_gtk2d_core-2.6.a /usr/local/lib/libwx_based-2.6.a 
-lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lpng -ljpeg -ltiff -lz -ldl -lm
app_wxluaedit_wxluaedit.o:(.rodata._ZTV16wxLuaEditorFrame[vtable for 
wxLuaEditorFrame]+0x374): undefined reference to 
`wxSTEditorFrame::UpdateFileListBox()'
collect2: ld returned 1 exit status
make[1]: *** [../bin/wxluaedit] Error 1
make[1]: Leaving directory `/home/klaas/soft/wxLua/apps'
make: *** [apps] Error 2
[klaas@localhost wxLua]$


John Labenski wrote:
> On 10/23/06, klaas.holwerda <kho...@xs...> wrote:
>   
>> Hi John,
>>