Menu
▾
▴
wxcode-users
|
From: klaas.holwerda <ng...@kl...> - 2009-05-09 09:46:28
|
Hi, When i enable in wxWidgets in config.vc the next: # Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set wxUSE_GRAPHICS_CONTEXT) [0,1] USE_GDIPLUS = 1 this result in linking errors in wxstedit ( and later also in wxLua) and all other modules i presume. So i add in the makefile.vc by hand the missing gdiplus.lib. I wonder how it would be possible to handle this directly in bakefile generated makefiles. For instance, build.cfg, contains the setting for USE_GDIPLUS, so it can be detected. A second bakefile related problem is that building debug and release of wxstedit, both result in the same library name: wcode_msw28_stedit But for debug it should generate: wcode_msw28d_stedit Francesco, are you able to fix that? ;-) Regards, Klaas |
|
From: John L. <jla...@gm...> - 2009-05-11 01:28:46
|
On Sat, May 9, 2009 at 5:46 AM, klaas.holwerda <ng...@kl...> wrote:
> Hi,
>
> When i enable in wxWidgets in config.vc the next:
>
> # Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set
> wxUSE_GRAPHICS_CONTEXT) [0,1]
> USE_GDIPLUS = 1
>
> this result in linking errors in wxstedit ( and later also in wxLua) and
> all other modules i presume.
> So i add in the makefile.vc by hand the missing gdiplus.lib.
>
> I wonder how it would be possible to handle this directly in bakefile
> generated makefiles.
> For instance, build.cfg, contains the setting for USE_GDIPLUS, so it can
> be detected.
>
I don't see how to automatically test for this, but we could add a condition
USE_GDIPLUS as wxWidgets does. Francesco, do you think this would work?
-------------------------------------------
Ripped from wxWidget's 2.8.10 config.bkl to be put into wxCode's
wx_win32.blk
<if cond="FORMAT!='autoconf'">
<option name="USE_GDIPLUS">
<values>0,1</values>
<default-value>0</default-value>
<description>
Link with gdiplus.lib? (Needed for wxGraphicsContext, will
also set wxUSE_GRAPHICS_CONTEXT)
</description>
</option>
</if>
<if cond="FORMAT_SUPPORTS_CONDITIONS=='0'">
<if cond="FORMAT!='autoconf'"><set var="USE_GDIPLUS">0</set></if>
</if>
-------------------------------------------
Ripped from wxWidget's 2.8.10 common.bkl to be put into wxCode's
wx_win32.blk
<if cond="FORMAT!='autoconf'">
<set var="GDIPLUS_LIB">
<if cond="USE_GDIPLUS=='1'">gdiplus</if>
</set>
</fi>
Put this after the line "<sys-lib>odbc32</sys-lib>" in wx.blk
<sys-lib>$(GDIPLUS_LIB)</sys-lib>
============================================
So I tried puttting this into wxCode's wx_win32.bkl and the output code
looks ok, but it's not tested. The dsp and vcproj are unchanged, but the
makefile.vc should work.
Index: presets/wx_win32.bkl
===================================================================
RCS file: /cvsroot/wxcode/wxCode/build/bakefiles/presets/wx_win32.bkl,v
retrieving revision 1.4
diff -b -u -2 -r1.4 wx_win32.bkl
--- presets/wx_win32.bkl 13 Feb 2008 14:00:13 -0000 1.4
+++ presets/wx_win32.bkl 11 May 2009 01:27:48 -0000
@@ -35,5 +35,23 @@
<!-- comments for more info. -->
+ <if cond="FORMAT!='autoconf'">
+ <option name="USE_GDIPLUS">
+ <values>0,1</values>
+ <default-value>0</default-value>
+ <description>
+ Link with gdiplus.lib? (Needed for wxGraphicsContext, set
to the value of wxUSE_GRAPHICS_CONTEXT)
+ </description>
+ </option>
+ </if>
+
+ <if cond="FORMAT_SUPPORTS_CONDITIONS=='0'">
+ <if cond="FORMAT!='autoconf'"><set var="USE_GDIPLUS">0</set></if>
+ </if>
+ <if cond="FORMAT!='autoconf'">
+ <set var="GDIPLUS_LIB">
+ <if cond="USE_GDIPLUS=='1'">gdiplus</if>
+ </set>
+ </if>
<!-- HELPER VARIABLES -->
@@ -248,4 +266,5 @@
<sys-lib>wsock32</sys-lib>
<sys-lib>odbc32</sys-lib>
+ <sys-lib>$(GDIPLUS_LIB)</sys-lib>
</if>
> A second bakefile related problem is that building debug and release of
> wxstedit, both result in the same library name:
> wcode_msw28_stedit
>
> But for debug it should generate:
>
> wcode_msw28d_stedit
>
I have rebaked the wxstedit build files in CVS and I see that the dsp files
put a 'd' in for debug so I assume that the makefile.vc should too.
>
> Francesco, are you able to fix that? ;-)
>
>
I hope he has time to look at the above.
-John
|
|
From: Francesco M. <f18...@ya...> - 2009-05-11 19:48:11
|
Hi John, Klaas, John Labenski ha scritto: > I don't see how to automatically test for this, but we could add a > condition USE_GDIPLUS as wxWidgets does. Francesco, do you think this > would work? > ... > Put this after the line "<sys-lib>odbc32</sys-lib>" in wx.blk > <sys-lib>$(GDIPLUS_LIB)</sys-lib> > > ============================================ > So I tried puttting this into wxCode's wx_win32.bkl and the output code > looks ok, but it's not tested. The dsp and vcproj are unchanged, but the > makefile.vc <http://makefile.vc> should work. I think it should just be fine. I think that in fact we have no changes we need to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a copy there just to facilitate baking for wxCode maintainers... so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 wxpresets... > A second bakefile related problem is that building debug and release of > wxstedit, both result in the same library name: > wcode_msw28_stedit > > But for debug it should generate: > > wcode_msw28d_stedit > > > I have rebaked the wxstedit build files in CVS and I see that the dsp > files put a 'd' in for debug so I assume that the makefile.vc > <http://makefile.vc> should too. Looking at the makefile.vc I see that the lib target is called: ..\lib\vc_$(____stedit_lib__DIRNAME_SHARED_SUFFIX_FILENAMES)\wxcode_msw$(WX_VERSION)$(WXLIBPOSTFIX)_stedit.lib and WXLIBPOSTFIX seems to be set correctly (i.e. contains 'u' and 'd' flags when required) so that I think everything is ok. Bye, Francesco |
|
From: klaas.holwerda <ng...@kl...> - 2009-05-11 20:04:50
|
Francesco Montorsi wrote: > and WXLIBPOSTFIX seems to be set correctly (i.e. contains 'u' and 'd' flags when > required) so that I think everything is ok. > Is it oke now, are was it oke before? I build today with wxstedit (not updated recently yet fromCVS), but it was wrong when using "nmake". So maybe there is something sneaky going on here. Will check once again. Best Regards, Klaas |
|
From: klaas.holwerda <ng...@kl...> - 2009-05-11 20:12:17
|
Francesco Montorsi wrote: > I think it should just be fine. I think that in fact we have no changes we need > to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a > copy there just to facilitate baking for wxCode maintainers... > so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 > wxpresets... > I hope so, but wxWidgets has its problems too when it comes to setting extra options :-) E.g. when i compile --with-opengl on linux, wxconfig --libs does not include the generated wxWidgets opengl library. So is it (wxpresets update) the same for/in wxLua to solve this problem?? Regards, Klaas |
|
From: Francesco M. <f18...@ya...> - 2009-05-16 10:09:08
|
klaas.holwerda ha scritto: > Francesco Montorsi wrote: >> I think it should just be fine. I think that in fact we have no changes we need >> to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a >> copy there just to facilitate baking for wxCode maintainers... >> so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 >> wxpresets... >> > I hope so, but wxWidgets has its problems too when it comes to setting > extra options :-) > E.g. when i compile --with-opengl on linux, wxconfig --libs does not > include the generated wxWidgets opengl library. well, that's ok for me however: if you compile with opengl, it doesn't mean that any app using wx-config needs wx openGL library, isn't it? If an app needs it, it can use "wx-config --libs gl" :) > So is it (wxpresets update) the same for/in wxLua to solve this problem?? yes, I think it's required also for wxLua... John, perhaps you already fixed it in wxLua, too? Francesco |
|
From: klaas.holwerda <ng...@kl...> - 2009-05-16 15:31:08
|
Francesco, I updated from CVS, but the linking problem is still there (gdiplus.lib is not in the makefile.vc. And with nmake it is a problem. Next i discovered that wxLua and wxstedit follow different ways to set unicode and debug. wxstedit: nmake -f makefile.vc WX_UNICODE=1 WX_DEBUG=1 wxLua & wxWidgets: nmake -f makefile.vc UNICODE=1 BUILD=debug Why this difference?? It is rather confusing. Because for that was the reason i thought the naming of the libs went wrong, but it is oke. I would not mind that all of them worked the same, or at least wxlua and wxCode stuff. Francesco Montorsi wrote: >> Francesco Montorsi wrote: >> >> > well, that's ok for me however: if you compile with opengl, it doesn't mean that > any app using wx-config needs wx openGL library, isn't it? > If an app needs it, it can use "wx-config --libs gl" :) > Oke forgot that one again, thanks for reminding :-) Regards, Klaas |
|
From: Francesco M. <f18...@ya...> - 2009-05-18 20:15:57
|
Hi Klaas, klaas.holwerda ha scritto: > Francesco, > > I updated from CVS, but the linking problem is still there (gdiplus.lib > is not in the makefile.vc. > And with nmake it is a problem. Yes, I see. It looks like John still has not committed his changes to the bakefiles... John, if you want, I can do it... > Next i discovered that wxLua and wxstedit follow different ways to set > unicode and debug. > > wxstedit: nmake -f makefile.vc WX_UNICODE=1 WX_DEBUG=1 > > wxLua & wxWidgets: nmake -f makefile.vc UNICODE=1 BUILD=debug > > Why this difference?? yes, I know of this difference; the problem is that with wxLua we choose to explicitely rename the default wxpresets' options WX_DEBUG and WX_UNICODE into BUILD and UNICODE. Originally in wxCode we chose to not use modified wxpresets as it was too confusing for the various maintainers. In wxCode this would be possible too, now (without having to use modified wxpresets). However IIRC I asked opinions about this on this mailing list and it was agreed that it was confusing to "suddenly" change WX_DEBUG=>BUILD as wxCode users were already used to WX_DEBUG and not BUILD (even if it's the name used by wx). > It is rather confusing. Because for that was the reason i thought the > naming of the libs went wrong, but it is oke. > I would not mind that all of them worked the same, or at least wxlua and > wxCode stuff. I agree it's confusing and I would like to change it. However other maintainers should agree on this, too... Maybe wx3.0 will be the good occasion to do this (as we will need some other [small] adjustments to the build system). Francesco |
|
From: John L. <jla...@gm...> - 2009-05-20 03:38:24
|
On Mon, May 18, 2009 at 4:15 PM, Francesco Montorsi <f18...@ya...
> wrote:
> Hi Klaas,
>
> klaas.holwerda ha scritto:
> > Francesco,
> >
> > I updated from CVS, but the linking problem is still there (gdiplus.lib
> > is not in the makefile.vc.
> > And with nmake it is a problem.
> Yes, I see. It looks like John still has not committed his changes to the
> bakefiles... John, if you want, I can do it...
>
Sorry about the delay, I looked at the wx.bkl, wx_win32.bkl, and wx_unix.blk
in wxWidgets 2.8.10 and wxCode/build/bakefiles/presets and they are really
very different. I was unsure about the rest of the changes, but I see that
you think it is best to hold off until 3.0.
I will commit the little change I posted before.
Regards,
John
|
|
From: John L. <jla...@gm...> - 2009-05-20 03:48:10
|
On Tue, May 19, 2009 at 11:38 PM, John Labenski <jla...@gm...> wrote: > On Mon, May 18, 2009 at 4:15 PM, Francesco Montorsi < > f18...@ya...> wrote: > >> Hi Klaas, >> >> klaas.holwerda ha scritto: >> > Francesco, >> > >> > I updated from CVS, but the linking problem is still there (gdiplus.lib >> > is not in the makefile.vc. >> > And with nmake it is a problem. >> Yes, I see. It looks like John still has not committed his changes to the >> bakefiles... John, if you want, I can do it... >> > > Sorry about the delay, I looked at the wx.bkl, wx_win32.bkl, and > wx_unix.blk in wxWidgets 2.8.10 and wxCode/build/bakefiles/presets and they > are really very different. I was unsure about the rest of the changes, but I > see that you think it is best to hold off until 3.0. > > I will commit the little change I posted before. > > Regards, > John > I have committed it, but it just dawns on me that since the MSVC GUI builds won't be able to have gdiplus.lib linked as an option, maybe we should just link to it all the time? Isn't it true that everyone has it and if you link to it, but don't use anything from it the linker throws it out. There's nothing to lose by doing that right? -John |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X