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
On 10/25/06, Klaas Holwerda <[EMAIL PROTECTED]> 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,
> >
In wxCode/build/bakefile/targets.bkl we have, which is similar as
COMP_WANT_UNINSTALL_WXHEADERS_TARGET.
$(COMP_BASEPATH)$(DIRSEP)include$(DIRSEP)wx$(DIRSEP)*.h
$(WX_DIR)$(DIRSEP)include$(DIRSEP)wx
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
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
and
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
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.
[EMAIL PROTECTED] a]$ ../configure
--prefix=/home/john/cvs/a/wxCode/components/wxstedit/a
checking for the --enable-debug option... will be automatically detected
...
che
