On OS X, what is the proper setting for $QTDIR? - macos

I'm trying to install QtROOT, and as part of the installation (specifically, the readme file in the QtROOT tarball at http://root.bnl.gov/QtRoot/downloads/qtFullRoot.tar.gz), it mentions to make sure that QTDIR is set. I've installed from the Qt 4.6.3 SDK installation for Mac OS X, and I have no such environment variable set. I've tried googling to figure out where it should be set to, but the options I've found (such as /usr/local/qt) don't exist. What should this variable be set to?
OS X 10.6.4, Qt 4.6.3, ROOT 5.26/00, QtROOT... I have no idea. :P
Thanks,
Paul

Qt's packaged installer for OSX scatters things throughout the /Developer and /Library directories rather than installing to a self-contained location in /usr/local or /opt/local as you might expect it to do on other unix-based systems.
Incidentally, Qt follows Apple's way of doing things in this respect, so it's really not wrong -- it's just different -- but it does make some 3rd party Qt applications somewhat difficult to build on OSX.
The packaged Qt installer itself has the following to say on this topic:
After a successful install, you can find most new things in /Developer. Specifically things will be located in the following places:
Qt Designer, Qt Linguist: /Developer/Applications/Qt
Qt Documentation: /Developer/Documentation/Qt
Qt Examples: /Developer/Examples/Qt
Qt Plugins: /Developer/Applications/Qt/Plugins
Qt Frameworks: /Library/Frameworks
Qt Libraries: /usr/lib
qmake, moc, uic, etc.: /Developer/Tools/Qt (symlink to /usr/bin)
Uninstall script: /Developer/Tools/uninstall-qt.py
So, it does put the libs into '/usr/lib', and it symlinks the essential Qt tools (like qmake) into '/usr/bin'. This suggests that QTDIR could be set to '/usr'. In practice however, this doesn't work because the qt headers remain buried in '/Library/Frameworks/Qt*/Headers/*.h', while builds that rely on $QTDIR will end up looking for the qt headers in "${QTDIR}/include/" instead.
The easiest way around all this is to build Qt from source. The install location will default to something like /usr/local/Trolltech/Qt-4.6.3 (note the version number, and adjust accordingly). You can override the default install location by using the -prefix option on ./configure.
A simpler approach is to let macports build it for you. This is the approach I ended up taking (and with good success). Just install macports, if you don't already have it. Then:
> sudo port selfupdate
> sudo port install qt4-mac
Macports will work its magic, and when it's done Qt will be installed, in its entirety, at /opt/local/libexec/qt4-mac.
Regardless of how you build Qt, expect a full build to take several hours. It's a very large code base.

I didn't install Qt from the installer (but compiled it myself), so I don't know the default location.
However, where you installed Qt, there is your QTDIR.
Search for qmake, it should reside in some bin/ folder. one up is QTDIR ($QTDIR/bin/qmake).
Usually it's not necessary anymore to set QTDIR these days to build a Qt project, just qmake must be in the PATH, everything else found then. But some projects might require it though (if they use a custom build system that still uses QTDIR).

I need to install LiteIDE on my mac and in the install guide, the QTDIR is necessary. I install the qt with the homebrew by brew install qt --build-from-source, it takes about 2 hours in RMBP. After the install finished, there is still no QTDIR path. By checking the build_osx.sh, i know it's just the parent folder of bin. so i set the path by export QTDIR=/usr/local/Cellar/qt/4.8.6. Then run the ./build_osx.sh again. it works.
Hope this will be helpful.

Related

qmake hangs in windows 7

I have a strange error with qmake: To compile octomap, first I need to compile octovis code, accordingly with documentation I need to use:
cd octovis/src/extern/QGLViewer
qmake
mingw32-make
But when I use qmake, they just do nothing, seeing the task monitor the amount of memory used is constant and the amount of processor used is 0.
I tried to uninstall/reinstall QT and MinGW, and didn't work, I have change the version of QT (4.8.5, 4.8.6, 5.5) and MinGW and didn't work, I'm using windows 7 over 64 bits. I appreciate any solution.
I was able to generate the qmake files with no problem. make failed, but my environment is QT 5.5.1, which I doubt is compatible. I can tell you how my environment is set up, and that should get you going.
Go ahead and download QT Creator for whatever version of QT you require. This includes the appropriate mingw version, so they don't need to be downloaded separately. http://download.qt.io/archive/qt/
Find out what version of QT is recommended. It looks like 4.X, but I'm not 100 percent certain.
Add X:/QTCREATOR/QTVERSION/mingw/bin to your system path, with QTCREATOR being the root directory for QT Creator and QTVERSION being the version. These are included with the QT Creator install.
Also add X:/QTCREATOR/Tools/mingw/bin to your system path.
I'm assuming you have CMake already. That's obviously required.
This should have your build environment set up properly. You're sure to encounter other problems along the way.
The best option appears to just run it under Linux. There are pre-compiled binaries.

trouble installing capybara-webkit on Windows8

I am following the tutorial:https://github.com/thoughtbot/capybara-webkit/wiki/Installing-Qt-and-compiling-capybara-webkit#gentoo-linux
and get stuck at step 11, where I get an error saying Command 'qmake -spec win32-g++ CONFIG+=test' not avalable.
I have no idea how to solve this, and I did add Qt/4.8.6/bin in the path.
I just spent a while getting this to work. I found that the QT environment/system variables were not set up correctly when QT installed. Short version: I found a problem with my Qt install: although it was in my path and qmake would run (I could do qmake -v and get output), that wasn't enough. The variables that Qt uses for paths (e.g. QT_INSTALL_HEADERS, etc.) were not correct. I had to run the Qt configuration program configure.exe. That correctly set all of the Qt variables and all was fixed.
I figured that it must be some kind of issue on my end, since I saw that others have installed it successfully. I went through each of the components required to verify the installation and setup -- and found the problem. I've been able to compile gems just fine using just DevKit, so suspected that it had something to do with Qt. (and it did) Here's what I did to check and verify each component:
DevKit: made sure it was installed in the ruby versions needed, and
verified that it worked:
checked '/devkit/config.yml' to make sure it listed each of different installed ruby versions, and then
re-ran the DevKit install script (ruby dk.rb install) to be sure that DevKit had installed the right files into each of those ruby versions.
I verified that DevKit was working using the recommendation on the DevKit page [https://github.com/oneclick/rubyinstaller/wiki/Development-Kit]: I installed the json gem. It was able to build the native version so that verified that DevKit was installed and working properly.
Qt: I downloaded the Qt files (I used 4.8.5; glad to know I can upgrade). I ran the .exe file downloaded to install them.
made sure that Qt directories were in my path (see the list below).
made sure that the environment variable QMAKESPEC was defined:QMAKESPEC=win32-g++
made the edits to the qmake.conf file (the 'Frommel workaround') as described on https://github.com/thoughtbot/capybara-webkit/wiki/Installing-Qt-and-compiling-capybara-webkit#windows
ran qmake -version to verify that qmake would run and to verify the version
ran qmake -query to verify the set-up for Qt. This is where I saw the problem with my Qt install: the paths were all wrong.
ran the Qt configure.exe program to fully configure my Qt install. This was the key step. (I thought that the initial installation program would have configured things, but obviously it didn't.) Running this will build all of the demos and examples and so takes a while. But when it completed, all was well.
ran qmake -query to verify that the Qt settings and been fixed and were correct.
System path and ENV variables: the following need to be in your path:
[devkit dir] (ex: C:\rubys\devkit-mingw64-32-4.7.2)
[devkit dir]\mingw\bin;
[devkit dir]\bin;
[qt dir] (ex: C:\Qt\qt-4.8.5-x86-mingw)
[qt dir]\bin;
[ruby version]\bin (ex: C:\rubys\ruby-2.0.0-p598-i386-mingw32\bin)
[ruby version]\lib\ruby\gems\
define the environment (system) variable QMAKESPEC=win32-g++ (If you don't give qmake/Qt the specification about which system to build for, it will look for this ENV.)
I know it's been a while since you posted your question, so hopefully you've solved it. If not, try these steps and see if they help.

Why doesn't OS X 10.8 Mountain Lion find X11 libraries when building software?

So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.

install Xcode in /usr

I have a makefile project that I would like to port to Xcode.
I was following the instructions on:
https://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/preparing/preparing.html
The document lists as important to install Xcode in the default "/usr" folder.
But the installer gives no such option.
And it installs the folder Devolopper in the "/" folder.
Is it safe to just move the whole content of "Developper" to "/usr" or should that be done during installation?
If so, how?
TFA says
If you are using makefiles for compilation, you should install Xcode in the default location (/usr). If you do not, you may have to do extra work to get your scripts to run the compiler, linker, and so on in a nonstandard location.
I'm guessing that the specific path is out of date, but the overall advice of installing Xcode in the standard place is sound. I recommend you use the Xcode installer, which puts make and gcc in the proper places and not worry about /usr in particular.
You certainly do NOT need to move /Developer to /usr. The docs must be talking about /usr/llvm-gcc-4.2/ folder and others which will be created when Xcode is installed into /Developer. You don't need to do anything special for that.
When Xcode tools are installed to the default location (/Developer), the installer creates aliases for developer tools in /usr locations automatically. Install and everything will just work: make, gcc, ld and everything else will appear in $PATH. In short, just install and that will be it.
I don't know why the doc says it that way, it must be mistake or misunderstanding.

What would be the best way to install (distribute) dynamic libraries in Mac OSX using CMake/Cpack?

I have a project whose artifacts are two dynamic libraries, let's say libX.dylib and libY.dylib (or .so for linux distributions). There are no executables.
Now I would like to distribute these libraries. Since I already use CMake to compile it, I looked at CPack and successfully generated .tgz and .deb packages for Linux. However, for Mac OSX I have no idea and the CPack Wiki about its generators did not help me much. I managed to generate a PackageMaker package, but as clearly stated at this packagemaker howto, there is no uninstall option when using this util. I then read a bit about Bundles, but I feel lost specially since I have no executable.
Question: What is the correct way to generate a package for Mac OSX using CPack?
My ideal scenario would be either something that installs as easily as a bundle or as a deb file in debian/ubuntu.
Thanks for your help
Edit
One more detail: the code to one of these libraries is not open, so I can't expect the users to do a cmake; make; make install
That's why I want a .deb, .tar.gz, bundle or whatsoever.
It depends on whether you want to install it the UNIX-y way (which is totally an ok thing to do, and actually my own preference as a Mac user) or if you want to install it as a Mac OS X Framework.
To install the libraries the UNIX-y way, you can use:
INSTALL(TARGETS target1 target2 DESTINATION lib)
In the above, replace target1 and target2 with the names of the targets that resulted in libX.dylib and libY.dylib being generated (i.e. whatever you used in ADD_LIBRARY). You can use the variable CMAKE_INSTALL_PREFIX in order to determine where the library ultimately ends up... with the above, if you set CMAKE_INSTALL_PREFIX to /usr/local, then it will install the libraries in /usr/local/lib
Edit
Based on your update, you may find Component Install with CPack and CPack Mac OS X PackageMaker Generator to be of interest. Since you will be installing libraries into the system, the PackageMaker generator is the one you should use. If you were merely distributing an application, then creating a ".app" bundle and distributing it in a ".dmg" would be the proper thing to do. PackageMaker is installed on Mac OS X when you install the Xcode Developer Tools. To package a ".app" bundle in a ".dmg", you can use the Mac OS X disk utility application or its associated commandline tools.

Resources