I wish people would trim their reply to lists I keep getting duplicates
from a lot of people. Uhhh.
On Mon, 31 Jan 2000, Arnd Hanses wrote:
> On Sun, 30 Jan 2000 23:06:39 -0800, Karl Nelson wrote:
>
> >One last suggestion is to rename sigc++config.h sigc++/config.h
> >in all the headers so tha
On Sun, 30 Jan 2000 23:06:39 -0800, Karl Nelson wrote:
>One last suggestion is to rename sigc++config.h sigc++/config.h
>in all the headers so that you don't need to include sigc++
>in your include paths. (and of course make the corresponding
>rename in the configure.in.)
Hi,
once again I'
> Karl,
> the sigc++ acconfig.in patch needed to get things to compile correctly on NT,
> did that go into CVS?
> Allan could you please include that?
Yep, the change is in. Since Allan is building from a CVS, it
should be in when he builds it with the most recent makeLyx script.
--Karl
Karl,
the sigc++ acconfig.in patch needed to get things to compile correctly on NT,
did that go into CVS?
Allan could you please include that?
Background: libsigc++-0.8.6 does not compile out of the box on cygnus-b20
because there are little issues with the configuration. Karl send me a patch
th
>
> Compile speed and saving a few extra bytes in the distribution. It is
> also a heavy handed way of forcing everyone to think carefully about why
> they want more than 2 parameters.
I have ways of vastly reducing the number of templates involved
but they are much to space hungry (involve cha
On Sun, 30 Jan 2000, Karl Nelson wrote:
> Okay, I will poke at it a bit. You really don't want to
> generate the *.h files in the src_dir though as it can mess some
> things up. Not a problem, I will just add $(builddir) to the include
> path as well to fix that.
You're right. I was in a hurr
> >
> > You likely need to add a "-I $(top_srcdir)/sigc++/macros" or something
> > to that effect in the Makefile.am.
>
> That will make m4 find the template.macros.m4 however the bigger problem
> is that the generated headers are put into:
> obj-libsigc++/sigc++/
> instead of
> lib
Okay, I will poke at it a bit. You really don't want to
generate the *.h files in the src_dir though as it can mess some
things up. Not a problem, I will just add $(builddir) to the include
path as well to fix that.
BTW, just curious why you are truncating the signal system numbers down?
Those
On Sun, 30 Jan 2000, Karl Nelson wrote:
> >
> > An extremely annoying thing about libsigc++ is that is doesn't support
> > VPATH compiles. So it has broken those for LyX unless you use an external
> > library.
>
> Not sure what a VPATH compile is. Care to clue me in?
> (I know autoconf well,
>
> An extremely annoying thing about libsigc++ is that is doesn't support
> VPATH compiles. So it has broken those for LyX unless you use an external
> library.
Not sure what a VPATH compile is. Care to clue me in?
(I know autoconf well, automake poorly, and rpm/deb not at all.)
> So if you
> I have thought a bit about this, and perhaps we should switch to the
> more generally accepted term: "Dialog".
> Popups are really something else...
I'm not sure if Allan already did this renaming, but I strongly agree
that we should use the term "dialog".
> - work on the painter
>
Karl Nelson <[EMAIL PROTECTED]> writes:
| > On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
| >
| > >The first draft of libsigc++ integration uses a slightly modified version
| > >of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
| > >you have a directory
On Thu, 27 Jan 2000 12:49:03 -0800, Karl Nelson wrote:
>> On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>>
>> >The first draft of libsigc++ integration uses a slightly modified version
>> >of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
>> >you have a
On Thu, 27 Jan 2000, Dr. Ing. Roland Krause wrote:
> Allan,
> long post indeed.
and getting longer...
>
> > I've cut down the number of signal and slot templates that are generated
> > (Signal0-Signal2 only for now
>
> I do not really see why you are doing this. At present it would be
> bette
> On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>
> >The first draft of libsigc++ integration uses a slightly modified version
> >of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
> >you have a directory called "sigc++"? What about OS/2?
>
> OS/2-HPFS (
Allan,
long post indeed.
Allan Rae wrote:
> I noticed you filed a report to the libsigc++ list.
Yes, I havent gotten any replies, I have not subscribed to the list but the issue
was:
libsigc++ version 0.8.5 compiles and works on cygnus b20 NT version 0.8.6 does not
compile due to a faulty confi
On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>The first draft of libsigc++ integration uses a slightly modified version
>of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
>you have a directory called "sigc++"? What about OS/2?
OS/2-HPFS (the standard):
I forgot to mention libsigc++ will drastically affect which compilers will
be able to compile LyX. It looks like gcc-2.7.2 will never work and
gcc-2.8.x is only just capable perhaps-maybe (sorry JMarc looks like
you'll have some extra work).
Libsigc++ is developed with egcs-1.1. It hasn't been
On 27 Jan 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> [I dropped the sigc++ list]
It was just Karl's private mail address not the list.
> So you are not letting the included sigc++ use its own ./configure?
My first draft does but its a pain -- 12 hours yesterd
Allan Rae <[EMAIL PROTECTED]> writes:
[I dropped the sigc++ list]
| I've cut down the number of signal and slot templates that are generated
| (Signal0-Signal2 only for now -- I don't see any need for more that number
| of parameters in our code [one return + two parameters] although that may
|
>> Allan Rae writes:
AR> On Wed, 3 Mar 1999, Allan Rae wrote:
>> There is a new gnome library for signals/slots. It is a totally
>> revised design of the gtk-- signal/slot mechanism which is even
>> more impressive in its capabilities than the original. They are
>> nearly ready to un
On Wed, 3 Mar 1999, Allan Rae wrote:
>
> There is a new gnome library for signals/slots. It is a totally revised
> design of the gtk-- signal/slot mechanism which is even more impressive in
> its capabilities than the original. They are nearly ready to unleash it
> on the world and need tester
22 matches
Mail list logo
