On 27-Feb-00 Chuck Robey wrote:
fine example, tho. We break the location of the config files that all
tcl
packages rely upon to build, for the purpose of allowing folks to run
multiple versions simultaneously. Tcl isn't the only one like that,
either. Anyone who wants to be able to build
On Sun, 27 Feb 2000, Daniel O'Connor wrote:
On 27-Feb-00 Chuck Robey wrote:
fine example, tho. We break the location of the config files that all
tcl
packages rely upon to build, for the purpose of allowing folks to run
multiple versions simultaneously. Tcl isn't the only one like
If memory serves me right, Daniel O'Connor said on 2000-02-27 23:43 +1030:
On 27-Feb-00 Chuck Robey wrote:
fine example, tho. We break the location of the config files that all
tcl
packages rely upon to build, for the purpose of allowing folks to run
multiple versions simultaneously. Tcl
On 27-Feb-00 Chuck Robey wrote:
This happens for tcl, gtk, qt.. There are quite a number. (at least 3! ;)
Can I ask you, why could this not have been done through a system of
symlinks and a little batch-file to switch them?
How could you run multiple applications which use different
On Mon, 28 Feb 2000, Daniel O'Connor wrote:
On 27-Feb-00 Chuck Robey wrote:
This happens for tcl, gtk, qt.. There are quite a number. (at least 3! ;)
Can I ask you, why could this not have been done through a system of
symlinks and a little batch-file to switch them?
How could you
On 27-Feb-00 Chuck Robey wrote:
Some stuff, like tclsh, could have a default link, say from tclsh to
tclsh8.2, or allow a user to set that. That could be a local option, but
it's icing on the cake as far as I'm concerned. The only real thing I
would be after is the ability to stick the
Not with the port. I was installing Qt to /usr/local/qt, and the port
was putting the libs in a non-standard place where KDE couldn't find
them. :-C I built Qt 1.45 by hand, installed it, set QTDIR, and
everything compiled fine. I haven't done much testing on it yet (only
ran kdehelp a
On Fri, 25 Feb 2000, Will Andrews wrote:
If you're gonna use a port, use ports for its dependencies too. You'd be
stupid not to use the ports whenever you can. No one has ever provided
me a convincing reason why this is not true.
Well when you want to keep multiple versions of kde or qt
ON that subject, has anyone tried compiling the KDE port with the
new QT145 port?
Not with the port. I was installing Qt to /usr/local/qt, and the port
was putting the libs in a non-standard place where KDE couldn't find
them. :-C I built Qt 1.45 by hand, installed it, set QTDIR, and
On Fri, Feb 25, 2000 at 03:02:58PM -0800, Joel Ray Holveck wrote:
Not with the port. I was installing Qt to /usr/local/qt, and the port
was putting the libs in a non-standard place where KDE couldn't find
them. :-C I built Qt 1.45 by hand, installed it, set QTDIR, and
everything compiled
Will Andrews wrote:
As far as I can tell, the KDE ports find Qt just fine. KDE insists on
putting everything under the same dir, as does Qt. This violates our
hierarchy (see hier(7) manpage), so we had to make some mods to the
configurations for Qt and KDE ports. It's not that difficult.
I am trying to build the kdelibs port on a -current that is 2 days old..
It fails like so...
gmake[2]: Entering directory
`/usr/tmp/work/usr/ports/x11/kdelibs11/work/kdelibs-1.1.2/kdecore'
/usr/X11R6/bin/moc ./kconfig.h -o kconfig.moc
/usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined
Daniel O'Connor wrote:
I am trying to build the kdelibs port on a -current that is 2 days old..
It fails like so...
gmake[2]: Entering directory
`/usr/tmp/work/usr/ports/x11/kdelibs11/work/kdelibs-1.1.2/kdecore'
/usr/X11R6/bin/moc ./kconfig.h -o kconfig.moc
/usr/libexec/ld-elf.so.1:
ON that subject, has anyone tried compiling the KDE port with the new QT145
port?
On 22-Feb-00 Maxim Sobolev wrote:
Daniel O'Connor wrote:
I am trying to build the kdelibs port on a -current that is 2 days old..
It fails like so...
gmake[2]: Entering directory
On Tue, 22 Feb 2000, Daniel O'Connor wrote:
I am trying to build the kdelibs port on a -current that is 2 days old..
It fails like so...
[...]
Now, I'd look this up in the mailing lists, but the search is still down :(
I do remember something about C++ stuff needing to be recompiled (which
On 22-Feb-00 Maxim Sobolev wrote:
Now, I'd look this up in the mailing lists, but the search is still down
I do remember something about C++ stuff needing to be recompiled (which
is
why I'm rebuilding kdelibs in the first place)..
You have to rebuild qt2 first to be able to run moc.
On Tue, Feb 22, 2000 at 05:36:19PM +0200, Maxim Sobolev wrote:
You have to rebuild qt2 first to be able to run moc.
ITYM Qt 1.45, not Qt2.
--
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+
On Tue, Feb 22, 2000 at 07:40:55AM -0800, William Woods wrote:
ON that subject, has anyone tried compiling the KDE port with the new QT145
port?
In my original tests, Qt 1.45 works fine with the KDE ports. Do you have
any problems with it?
--
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d-
Yea, after I compiled QT145, I couldent compile KDE. I am not sure of the exact
error, it was a few days ago and I went back to 142, but It wouldent comile.
On 22-Feb-00 Will Andrews wrote:
On Tue, Feb 22, 2000 at 07:40:55AM -0800, William Woods wrote:
ON that subject, has anyone tried
On Tue, 22 Feb 2000, William Woods wrote:
On 22-Feb-00 Will Andrews wrote:
On Tue, Feb 22, 2000 at 07:40:55AM -0800, William Woods wrote:
ON that subject, has anyone tried compiling the KDE port with the new QT145
port?
In my original tests, Qt 1.45 works fine with the KDE ports. Do
20 matches
Mail list logo
