22 Feb
2011
22 Feb
'11
9:58 p.m.
Calvin wrote:
On an Intel Atom it takes much longer than 5 minutes :P It broke again D:
Do you think it is related to the environmental variables?
Hmmm..
(1.) The very first thing I want to do is confirm that you have the following
built and installed in this order, so show us 'pacman -Q | grep trinity':
15:34 supersff:~> pacman -Q | grep trinity # then I manually sorted
trinity-qt3 3.3.8-20
trinity-pyqt3 3.18.1-9
trinity-tqtinterface 1221148-1
trinity-arts 1214641-1
trinity-kdelibs 1222098-1
Your stuck at 37% on
trinity-kdebase 1221588-1
(2.) Please post the error you received after rebuilding with 'make VERBOSE=1'
in the build() function. (it will provide a little more info that will help)
Your environment for the build is set within the PKGBUILD file so it shouldn't
matter what your existing shell environment is:
export CMAKE_PREFIX_PATH=/opt/qt:/opt/trinity
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
export LD_LIBRARY_PATH=/opt/trinity/lib:/opt/trinity/lib/kde3:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=:/opt/trinity/lib/pkgconfig:/opt/qt/lib/pkgconfig
The build environment will be influenced by
/etc/ld.so.conf.d/trinity-kdelibs.conf. So if you have trinity-kdelibs installed:
(3.) confirm you have
cat /etc/ld.so.conf.d/trinity-kdelibs.conf
/opt/trinity/lib
(4.) As root, run ldconfig if the trinity-kdelibs.conf so the linker cache
magic is updated.
What I want to confirm is that you are NOT trying to build on a system with
KDE4/Qt4 or kdemod3 installed. That will screw up your build because of the
conflicting libraries that cmake has trouble ignoring. So:
(5.) look at:
pacman -Q | grep "qt\|kde"
If you have:
qt 4.7.1-3
kdemod3-<anything> 3.5.10-1
kde<xyz>-<anything> 4.6.0-2
The build will fail.
I don't know how a build between a normal i686, x86_64 and an Intel Atom will
differ, but I haven't heard anything that says building on an Intel Atom won't
work -- or that it *will* work for that matter. So let's take it step by step.
Change into
trinity-qt3
do 'makepkg -sf --noextract' to do a quick rebuild of the existing package and
install it with 'sudo pacman -U trinity-qt3-<version>.xz.
do the same thing for trinity-pyqt3
Change into
trinity-tqtinterface - a simple makepkg -sf and install with 'sudo pacman -U
trinity-tqtinterface-<version>.xz.
Do the same thing for 'trinity-arts' and 'trinity-kdelibs'. After
'trinity-kdelibs' is installed - and run (as root) ldconfig.
(6.) Change into
trinity-kdebase - and restart the build with 'make VERBOSE=1' and post the
output if it fails again.
I'm scratching my head on this one. I've literally built Trinity 5-6 times in
the past 2 days using the build script and gotten no errors during the make. So
the PKGBUILDs work. If there is something special we need to do for the Intel
Atom, then that's something we will have to look into. But, to get started, we
need the information requesting in (1.) - (6.) above :)
--
David C. Rankin, J.D.,P.E.
22 Feb
22 Feb
10:24 p.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 02/22/2011 03:58 PM, David C. Rankin wrote:
Calvin wrote:
On an Intel Atom it takes much longer than 5 minutes :P It broke again D:
Do you think it is related to the environmental variables?
Hmmm..
<snip>
Calvin, I have found a missing export. Change:
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
I'm updating the PKGBUILD now :) (long lines - must have deleted an export
accidentally :(
--
David C. Rankin, J.D.,P.E.
11:28 p.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 02/22/2011 04:24 PM, David C. Rankin wrote:
On 02/22/2011 03:58 PM, David C. Rankin wrote:
Calvin, I have found a missing export. Change:
<snip>
Calvin,
I just ran another build - no problems :) Here is the bldlog.txt file from the
latest build:
http://www.3111skyline.com/dl/dt/trinity/tmp/bldlog.txt
I suspect that the CMAKE_INCLUDE_PATH gave me no problems due to already having
Trinity installed and pkgconfig taking care of the path for me. Let me know if
you have gotten kdebase to build.
The current package list on i686 is:
17:24 supersff:~/tblds> pacman -Q | grep trinity
trinity-arts 1214641-1
trinity-kdebase 1221588-1
trinity-kdelibs 1222098-1
trinity-kdevelop 1221512-1
trinity-kdewebdev 1216789-1
trinity-pyqt3 3.18.1-9
trinity-qt3 3.3.8-20
trinity-tqtinterface 1221148-1
--
David C. Rankin, J.D.,P.E.
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
11:49 p.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
Well long story short, I am glad that it works for you. but if more
than one person can't build it, the whole PKGBUILD system becomes
worthless.
Thanks for updating the PKGBUILD i'll take a look at it.
I do have qt4 installed (hmm you seem to have mentioned that before)
BUT that shouldn't interfere with it afaik.
On 22 February 2011 18:28, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
On 02/22/2011 04:24 PM, David C. Rankin wrote:
On 02/22/2011 03:58 PM, David C. Rankin wrote:
Calvin, I have found a missing export. Change:
<snip>
Calvin,
I just ran another build - no problems :) Here is the bldlog.txt file from the
latest build:
http://www.3111skyline.com/dl/dt/trinity/tmp/bldlog.txt
I suspect that the CMAKE_INCLUDE_PATH gave me no problems due to already having
Trinity installed and pkgconfig taking care of the path for me. Let me know if
you have gotten kdebase to build.
The current package list on i686 is:
17:24 supersff:~/tblds> pacman -Q | grep trinity
trinity-arts 1214641-1
trinity-kdebase 1221588-1
trinity-kdelibs 1222098-1
trinity-kdevelop 1221512-1
trinity-kdewebdev 1216789-1
trinity-pyqt3 3.18.1-9
trinity-qt3 3.3.8-20
trinity-tqtinterface 1221148-1
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
23 Feb
23 Feb
12:31 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 02/22/2011 05:49 PM, calvin morrison wrote:
I do have qt4 installed (hmm you seem to have
mentioned that before)
BUT that shouldn't interfere with it afaik.
Oh yes it will :(
There are several problems, see thread:
[trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h
QT_BEGIN_HEADER doesn't name type
There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to use it
instead of uic from trinity. (you can try and trick it by putting
/opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a risky hack.
Then there is:
<quote>
If kde4/Qt4 is installed, cmake fails when it uses
/usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I cannot figure out how to tell cmake to ignore the /usr/include. I have tried
the cmake arguments:
cmake ../ \
-DCMAKE_INSTALL_PREFIX=${trinity_prefix} \
-DWITH_QT3=ON \
-DQTDIR=/opt/qt \
-DBUILD_ALL=ON
</quote>
<reply>
They are right, some KDE3 applications where no amount of
configuration helps only build properly in a clean chroot, without the
KDE4 stuff around.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro…
</reply>
So even though you can *INSTALL* Trinity next to kde4, that doesn't mean you can
*BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building trinity
based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a system
with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity with Qt4
present :)
The PKGBUILD files are correct, but they don't work magic :p
Set up a clean build environment in VirtualBox. Alocate ~15G to the install,
(you could probably get away with 8G total). For a 15G VM allocate 5G '/', 120M
'/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to
install
base and base-devel packages and all you have to do is hit 'return' and the Arch
defaults for partitioning, etc. are fine.
Then what I did was just to setup my existing /home/david dir as a shared folder
in VirtualBox to provide access to all my files and provide a place to save
finished packages so they exist outside the VM. Then in the VirtualBox guest
install of Arch, just create your /home/calvin/builds, set the paths for the
bldtrinsvn-all.sh to use that as your builds dir and point the srcdir and pkgdir
path to the shared folder on your original /home/calvin that you shared with
your guest as something like 'hhome' (short for host home) and start building.
No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
Some software just needs a clean build environment to build properly. It has
nothing to do with running it, it just has to build without the presents of
conflicting files.
--
David C. Rankin, J.D.,P.E.
1:02 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 22/02/2011, David C. Rankin <drankinatty(a)suddenlinkmail.com> wrote:
On 02/22/2011 05:49 PM, calvin morrison wrote:
It seems this is a case where we would need a make-conflict. but that
doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to
our make depends and require that (qt < 4).
Can we resolve this issue another way?
Calvin
I do have qt4 installed (hmm you seem to have
mentioned that before)
BUT that shouldn't interfere with it afaik.
Oh yes it will :(
There are several problems, see thread:
[trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h
QT_BEGIN_HEADER doesn't name type
There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to use
it
instead of uic from trinity. (you can try and trick it by putting
/opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a risky
hack.
Then there is:
<quote>
If kde4/Qt4 is installed, cmake fails when it uses
/usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I cannot figure out how to tell cmake to ignore the /usr/include. I have
tried
the cmake arguments:
cmake ../ \
-DCMAKE_INSTALL_PREFIX=${trinity_prefix} \
-DWITH_QT3=ON \
-DQTDIR=/opt/qt \
-DBUILD_ALL=ON
</quote>
<reply>
They are right, some KDE3 applications where no amount of
configuration helps only build properly in a clean chroot, without the
KDE4 stuff around.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro…
</reply>
So even though you can *INSTALL* Trinity next to kde4, that doesn't mean you
can
*BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building
trinity
based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a system
with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity with
Qt4
present :)
The PKGBUILD files are correct, but they don't work magic :p
Set up a clean build environment in VirtualBox. Alocate ~15G to the
install,
(you could probably get away with 8G total). For a 15G VM allocate 5G '/',
120M
'/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to
install
base and base-devel packages and all you have to do is hit 'return' and the
Arch
defaults for partitioning, etc. are fine.
Then what I did was just to setup my existing /home/david dir as a shared
folder
in VirtualBox to provide access to all my files and provide a place to save
finished packages so they exist outside the VM. Then in the VirtualBox guest
install of Arch, just create your /home/calvin/builds, set the paths for the
bldtrinsvn-all.sh to use that as your builds dir and point the srcdir and
pkgdir
path to the shared folder on your original /home/calvin that you shared with
your guest as something like 'hhome' (short for host home) and start
building.
No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
Some software just needs a clean build environment to build properly. It has
nothing to do with running it, it just has to build without the presents of
conflicting files.
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
1:06 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 22/02/2011, calvin morrison <mutantturkey(a)gmail.com> wrote:
On 22/02/2011, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
It seems also that we can ignore libs with cmake!
http://www.mail-archive.com/cmake@cmake.org/msg09583.html
/NODEFAULTLIB maybe the answer to the problem.
I have yet to find how to use this (unfimiliar with cmake)
Calvin
On 02/22/2011 05:49 PM, calvin morrison wrote:
It seems this is a case where we would need a make-conflict. but that
doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to
our make depends and require that (qt < 4).
Can we resolve this issue another way?
Calvin
I do have qt4 installed (hmm you seem to have
mentioned that before)
BUT that shouldn't interfere with it afaik.
Oh yes it will :(
There are several problems, see thread:
[trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h
QT_BEGIN_HEADER doesn't name type
There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to
use
it
instead of uic from trinity. (you can try and trick it by putting
/opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a
risky
hack.
Then there is:
<quote>
If kde4/Qt4 is installed, cmake fails when it uses
/usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I cannot figure out how to tell cmake to ignore the /usr/include. I have
tried
the cmake arguments:
cmake ../ \
-DCMAKE_INSTALL_PREFIX=${trinity_prefix} \
-DWITH_QT3=ON \
-DQTDIR=/opt/qt \
-DBUILD_ALL=ON
</quote>
<reply>
They are right, some KDE3 applications where no amount of
configuration helps only build properly in a clean chroot, without the
KDE4 stuff around.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro…
</reply>
So even though you can *INSTALL* Trinity next to kde4, that doesn't mean
you
can
*BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building
trinity
based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a
system
with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity
with
Qt4
present :)
The PKGBUILD files are correct, but they don't work magic :p
Set up a clean build environment in VirtualBox. Alocate ~15G to the
install,
(you could probably get away with 8G total). For a 15G VM allocate 5G
'/',
120M
'/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to
install
base and base-devel packages and all you have to do is hit 'return' and
the
Arch
defaults for partitioning, etc. are fine.
Then what I did was just to setup my existing /home/david dir as a shared
folder
in VirtualBox to provide access to all my files and provide a place to
save
finished packages so they exist outside the VM. Then in the VirtualBox
guest
install of Arch, just create your /home/calvin/builds, set the paths for
the
bldtrinsvn-all.sh to use that as your builds dir and point the srcdir and
pkgdir
path to the shared folder on your original /home/calvin that you shared
with
your guest as something like 'hhome' (short for host home) and start
building.
No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
Some software just needs a clean build environment to build properly. It
has
nothing to do with running it, it just has to build without the presents
of
conflicting files.
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
1:46 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 22/02/2011, calvin morrison <mutantturkey(a)gmail.com> wrote:
On 22/02/2011, calvin morrison
<mutantturkey(a)gmail.com> wrote:
So I've worked out (sorry for triple posting) what the tentative solution is,
cmake documentation says:
CMAKE_EXE_LINKER_FLAGS: Linker flags used to create executables.
Flags used by the linker when creating an executable.
So all we have to do is set the flags right for ld to ignore the Qt4 libs.
ld has a option " -z nodefaultlib " once i figure out how this works,
all we have to do is add another export line for the
CMAKE_EXE_LINKER_FLAGS and that should fix the problem AFAIK.
Calvin
On 22/02/2011, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
It seems also that we can ignore libs with cmake!
http://www.mail-archive.com/cmake@cmake.org/msg09583.html
/NODEFAULTLIB maybe the answer to the problem.
I have yet to find how to use this (unfimiliar with cmake)
Calvin
On 02/22/2011 05:49 PM, calvin morrison wrote:
It seems this is a case where we would need a make-conflict. but that
doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to
our make depends and require that (qt < 4).
Can we resolve this issue another way?
Calvin
I do have qt4 installed (hmm you seem to have
mentioned that before)
BUT that shouldn't interfere with it afaik.
Oh yes it will :(
There are several problems, see thread:
[trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h
QT_BEGIN_HEADER doesn't name type
There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to
use
it
instead of uic from trinity. (you can try and trick it by putting
/opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a
risky
hack.
Then there is:
<quote>
If kde4/Qt4 is installed, cmake fails when it uses
/usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I cannot figure out how to tell cmake to ignore the /usr/include. I have
tried
the cmake arguments:
cmake ../ \
-DCMAKE_INSTALL_PREFIX=${trinity_prefix} \
-DWITH_QT3=ON \
-DQTDIR=/opt/qt \
-DBUILD_ALL=ON
</quote>
<reply>
They are right, some KDE3 applications where no amount of
configuration helps only build properly in a clean chroot, without the
KDE4 stuff around.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro…
</reply>
So even though you can *INSTALL* Trinity next to kde4, that doesn't mean
you
can
*BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building
trinity
based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a
system
with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity
with
Qt4
present :)
The PKGBUILD files are correct, but they don't work magic :p
Set up a clean build environment in VirtualBox. Alocate ~15G to the
install,
(you could probably get away with 8G total). For a 15G VM allocate 5G
'/',
120M
'/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to
install
base and base-devel packages and all you have to do is hit 'return' and
the
Arch
defaults for partitioning, etc. are fine.
Then what I did was just to setup my existing /home/david dir as a
shared
folder
in VirtualBox to provide access to all my files and provide a place to
save
finished packages so they exist outside the VM. Then in the VirtualBox
guest
install of Arch, just create your /home/calvin/builds, set the paths for
the
bldtrinsvn-all.sh to use that as your builds dir and point the srcdir
and
pkgdir
path to the shared folder on your original /home/calvin that you shared
with
your guest as something like 'hhome' (short for host home) and start
building.
No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
Some software just needs a clean build environment to build properly. It
has
nothing to do with running it, it just has to build without the presents
of
conflicting files.
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
3:51 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 02/22/2011 07:46 PM, calvin morrison wrote:
So I've worked out (sorry for triple posting) what
the tentative solution is,
cmake documentation says:
CMAKE_EXE_LINKER_FLAGS: Linker flags used to create executables.
Flags used by the linker when creating an executable.
So all we have to do is set the flags right for ld to ignore the Qt4 libs.
ld has a option " -z nodefaultlib " once i figure out how this works,
all we have to do is add another export line for the
CMAKE_EXE_LINKER_FLAGS and that should fix the problem AFAIK.
Calvin
YES - Amen. This is how it needs to be done.
I have no doubt that the Trinity cmake files will ultimately get tailored to
do this correctly. But I understand the priorities. These tweaks lie somewhere
on the time-line between:
+-------------------------------|------------------------------------+
Port all Modules Tweak CMake files Finished Trinity
to CMake and to ignore other 3.5.13 Super
get building in existing packages Desktop
clean environ possibly present
(** Not to scale :-)
--
David C. Rankin, J.D.,P.E.
3:39 a.m.
New subject: [trinity-devel] Trinity on Arch - Intel Atom (new thread)
On 02/22/2011 07:02 PM, calvin morrison wrote:
It seems this is a case where we would need a
make-conflict. but that
doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to
our make depends and require that (qt < 4).
Can we resolve this issue another way?
Calvin
I think all of this can be handled in the CMake files, but it will take detailed
effort from somebody way smarter than I am to insure the CMake build process
only uses the proper Qt version and proper libraries associated with the
DCMAKE_INSTALL_PREFIX=${trinity_prefix}, -DWITH_QT3=ON, -DQTDIR=/opt/qt or
similar options.
I know cmake can do it, I just don't know how or where to tell it to do it :(
That's why after fighting the weird build errors and trying to prevent the build
from looking in /usr for includes and Qt libraries, I just threw in the towel
and set up a clean build environment. (it also let me catch all needed
dependencies and specify them in the PKGBUILDs)
--
David C. Rankin, J.D.,P.E.
5071
days inactive
5072
days old
9 comments
2 participants
participants (2)
-
calvin morrison -
David C. Rankin