Qt-interest Archive, August 2007
Hardcoded paths to Qt installation in various binaries(win-opensource/mingw).
Pages: Prev | 1 | 2 | 3 | Next
Message 1 in thread
Hi.
I encountered a problem: the inability to build an path-independent Qt
development package.
I built Qt-4.3.1 together with STLport-5.1.3(without any problems
during the build-process) and was surprised that after I've moved the
directory in which the build was held, all Qt development
tools(qmake, assistant, etc.) stopped working.
I discovered that the *full* build-path(i.e.
e:/.my/projects/install/qt-test) is hardcoded in almost all binaries
and in all *.prl files in lib-dir.
I could not believe it and I installed the
qt-win-opensource-4.3.1-mingw.exe package and I confused that there,
after extracting files, was steps like "patching xxx.prl"/"patching
paths qmake"/"patching paths core".
We all know that hardcoding anything is
antipattern( http://en.wikipedia.org/wiki/Hard_code ), but I did not
expect to see this antipattern in so carefully designed toolkit as Qt.
Clearly, if Qt could not working with the relative paths, it could
even make it dependent on the environment variable. As Qt uses QTDIR
environment variable?
Ok, so all sentimental talks, let's move close to the case.
1. Please, remove all hardcoded paths from next releases.
2. How can I solve my problem with path-independent development
environment now(with latest release: qt-4.3.1)? Is there any patcher,
that I can use when moving environment to another computer/another
path? Maybe I could create something like your installer
qt-win-opensource-4.3.1-mingw.exe?
I await your comments. Thank you for the best developers' toolkit.
--
[ signature omitted ]
Message 2 in thread
On 26.08.07 14:03:43, Vadim Doroginin wrote:
> I encountered a problem: the inability to build an path-independent Qt
> development package.
It is possible, the kdewin-installer for KDE4/win32 provides Qt packages
that can be put anywhere. The important bit is a qt.conf file in the
main Qt dir.
> We all know that hardcoding anything is
> antipattern( http://en.wikipedia.org/wiki/Hard_code ),
Thats stupid (I don't mean the article, didn't even read it), but the
"hardcoding is antipattern". For some things that might be right, but
for installation paths of programs thats total nonsense. Especially for
libs, other apps have to have a way to find the library and that without
the user being forced to do anything extra to his system (for example
setting an env var)
> Clearly, if Qt could not working with the relative paths,
ROFL. How do you expect qmake to know the right relative path for the Qt
installation directory given the absolute path of a .pro file? It always
needs the absolute path of the install dir to know which is the right
relative path for putting into the Makefile.
Apart from that: I've never seen designer or linguist needing Qt in a
specific path, all those apps need is the qt libs besides them and
eventually the plugins at a proper place (and that stuff is documented
IIRC)
> it could even make it dependent on the environment variable. As Qt
> uses QTDIR environment variable?
No env vars are bad, because they force the user to set them up
properly instead of qmake (just taking it as an example here) working
out of the box. Apart from that: TT doesn't support QTDIR anymore with
Qt4. It still does support QMAKESPEC to choose a different dir for the
mkspecs.
> 1. Please, remove all hardcoded paths from next releases.
Won't happen I think. Apart from that: Wrong adress, this is about using
Qt, not reporting bugs or feature wishes. Use the proper reporting
channels.
> 2. How can I solve my problem with path-independent development
> environment now(with latest release: qt-4.3.1)? Is there any patcher,
> that I can use when moving environment to another computer/another
> path? Maybe I could create something like your installer
> qt-win-opensource-4.3.1-mingw.exe?
You could ask on the kde-windows mailinglist (see lists.kde.org for more
information) on how the qt4-packages for the kdewin-installer are built.
Andreas
--
[ signature omitted ]
Message 3 in thread
On 8/26/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> On 26.08.07 14:03:43, Vadim Doroginin wrote:
> > I encountered a problem: the inability to build an path-independent Qt
> > development package.
>
> It is possible, the kdewin-installer for KDE4/win32 provides Qt packages
> that can be put anywhere. The important bit is a qt.conf file in the
> main Qt dir.
Thanks. I'll discover that.
>
> > We all know that hardcoding anything is
> > antipattern( http://en.wikipedia.org/wiki/Hard_code ),
>
> Thats stupid (I don't mean the article, didn't even read it), but the
> "hardcoding is antipattern". For some things that might be right, but
> for installation paths of programs thats total nonsense. Especially for
> libs, other apps have to have a way to find the library and that without
> the user being forced to do anything extra to his system (for example
> setting an env var)
>
> > Clearly, if Qt could not working with the relative paths,
>
> ROFL. How do you expect qmake to know the right relative path for the Qt
> installation directory given the absolute path of a .pro file? It always
> needs the absolute path of the install dir to know which is the right
> relative path for putting into the Makefile.
Yes, of course, qmake should know absolute path to Qt installation.
I'm talking about paths, relative to Qt installation(such as bin, lib,
docs, etc.).
You want to say, that qmake can't detect absolute qt installation path
without of hardcoding it o_0? Ha-ha. No, I don't saying that there is
pure-c++ way to detect it, but I convinced, that each OS provide a
simple way to detect application path.
> Apart from that: I've never seen designer or linguist needing Qt in a
> specific path, all those apps need is the qt libs besides them and
> eventually the plugins at a proper place (and that stuff is documented
> IIRC)
What about windows? For example I want to place most of development
stuff onto CD/DVD.
There is documented drive letter for CD? Maybe, but computers, where I
have to develop my projects each have different letters for that
drive.
> > it could even make it dependent on the environment variable. As Qt
> > uses QTDIR environment variable?
>
> No env vars are bad, because they force the user to set them up
> properly instead of qmake (just taking it as an example here) working
> out of the box. Apart from that: TT doesn't support QTDIR anymore with
> Qt4. It still does support QMAKESPEC to choose a different dir for the
> mkspecs.
>
> > 1. Please, remove all hardcoded paths from next releases.
>
> Won't happen I think. Apart from that: Wrong adress, this is about using
> Qt, not reporting bugs or feature wishes. Use the proper reporting
> channels.
What channels? I found only xx-interest lists :(.
> > 2. How can I solve my problem with path-independent development
> > environment now(with latest release: qt-4.3.1)? Is there any patcher,
> > that I can use when moving environment to another computer/another
> > path? Maybe I could create something like your installer
> > qt-win-opensource-4.3.1-mingw.exe?
>
> You could ask on the kde-windows mailinglist (see lists.kde.org for more
> information) on how the qt4-packages for the kdewin-installer are built.
Thanks, I'll try.
> Andreas
>
> --
> It's a very *__ UN*lucky week in which to be took dead.
> -- Churchy La Femme
--
[ signature omitted ]
Message 4 in thread
On 26.08.07 16:22:16, Vadim Doroginin wrote:
> On 8/26/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> > On 26.08.07 14:03:43, Vadim Doroginin wrote:
> > > We all know that hardcoding anything is
> > > antipattern( http://en.wikipedia.org/wiki/Hard_code ),
> >
> > Thats stupid (I don't mean the article, didn't even read it), but the
> > "hardcoding is antipattern". For some things that might be right, but
> > for installation paths of programs thats total nonsense. Especially for
> > libs, other apps have to have a way to find the library and that without
> > the user being forced to do anything extra to his system (for example
> > setting an env var)
> >
> > > Clearly, if Qt could not working with the relative paths,
> >
> > ROFL. How do you expect qmake to know the right relative path for the Qt
> > installation directory given the absolute path of a .pro file? It always
> > needs the absolute path of the install dir to know which is the right
> > relative path for putting into the Makefile.
>
> Yes, of course, qmake should know absolute path to Qt installation.
> I'm talking about paths, relative to Qt installation(such as bin, lib,
> docs, etc.).
Why should those be stored relative? You can't change qmake's
QT_INSTALL_PREFIX (IIRC) unless you recompile qmake. Apart from that the
opensource-windows version can't "install" anyway, thats simply not
supported. The opensource-windows version can only be used from the
place where you unpacked it (unless you rebuilt it in a new place).
> You want to say, that qmake can't detect absolute qt installation path
> without of hardcoding it o_0? Ha-ha. No, I don't saying that there is
> pure-c++ way to detect it, but I convinced, that each OS provide a
> simple way to detect application path.
Uhm, its possible to have the libs in /usr/lib, the includes in
/usr/include/qt4, the mkspecs in /usr/share/qt4/mkspecs and the bins in
/opt/bin if you want (thats for linux, as I said for windows/opensource
this whole discussion is moot because that version doesn't support
installing). And qmake only knows /opt/bin it can't guess the rest of
the paths. And then think about people that use symlinks, then /opt/bin
might in fact be /usr/local/bin and if qmake would know that lib dir is
in "../../usr/lib" it would fail because the absolute path it would know
from the OS would be /usr/local/bin (i.e. no symlinks).
Coding the installation path into the binary is IMHO perfectly fine and
is being done with nearly any library I know - in some way or the other
(think foo-config or pkg-config).
> > Apart from that: I've never seen designer or linguist needing Qt in a
> > specific path, all those apps need is the qt libs besides them and
> > eventually the plugins at a proper place (and that stuff is documented
> > IIRC)
>
> What about windows? For example I want to place most of development
> stuff onto CD/DVD.
> There is documented drive letter for CD? Maybe, but computers, where I
> have to develop my projects each have different letters for that
> drive.
I don't see a linux/unix-specific thing in my statement you quoted.
Anyway, yes thats not supported by Qt if you don't have the same drive
letter (well a OS with drive letters is broken anyway, but thats a
different story ;). But win2k/winxp/vista can easily change the drive
letter of the CD/DVD drive, thats a 5 minute job. Of course that imposes
a problem if you don't work on that machine alone. OTOH it takes about 5
minutes to install a Qt onto a PC and another 5 minutes when you need to
do an update. Unless you're developing on some 3 dozen machines (in
which case you've got other problems than just syncing Qt, but all the
other software and you need some software distribution system anyway)
thats not really a problem, IMHO.
Just out of curiosity: Do you create/update your CD/DVD every 2 or 3
months when TT releases a new Qt version?
> > > it could even make it dependent on the environment variable. As Qt
> > > uses QTDIR environment variable?
> >
> > No env vars are bad, because they force the user to set them up
> > properly instead of qmake (just taking it as an example here) working
> > out of the box. Apart from that: TT doesn't support QTDIR anymore with
> > Qt4. It still does support QMAKESPEC to choose a different dir for the
> > mkspecs.
> >
> > > 1. Please, remove all hardcoded paths from next releases.
> >
> > Won't happen I think. Apart from that: Wrong adress, this is about using
> > Qt, not reporting bugs or feature wishes. Use the proper reporting
> > channels.
>
> What channels? I found only xx-interest lists :(.
Check the website, there are feedback channels for exactly this purpose.
You're not even guaranteed that TT reads your email on this list,
because this is not an official TT channel. Its more like a qt-users
list.
Andreas
--
[ signature omitted ]
Message 5 in thread
On 8/26/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> On 26.08.07 16:22:16, Vadim Doroginin wrote:
> > On 8/26/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> > > On 26.08.07 14:03:43, Vadim Doroginin wrote:
> > > > We all know that hardcoding anything is
> > > > antipattern( http://en.wikipedia.org/wiki/Hard_code ),
> > >
> > > Thats stupid (I don't mean the article, didn't even read it), but the
> > > "hardcoding is antipattern". For some things that might be right, but
> > > for installation paths of programs thats total nonsense. Especially for
> > > libs, other apps have to have a way to find the library and that without
> > > the user being forced to do anything extra to his system (for example
> > > setting an env var)
> > >
> > > > Clearly, if Qt could not working with the relative paths,
> > >
> > > ROFL. How do you expect qmake to know the right relative path for the Qt
> > > installation directory given the absolute path of a .pro file? It always
> > > needs the absolute path of the install dir to know which is the right
> > > relative path for putting into the Makefile.
> >
> > Yes, of course, qmake should know absolute path to Qt installation.
> > I'm talking about paths, relative to Qt installation(such as bin, lib,
> > docs, etc.).
>
> Why should those be stored relative? You can't change qmake's
> QT_INSTALL_PREFIX (IIRC) unless you recompile qmake. Apart from that the
> opensource-windows version can't "install" anyway, thats simply not
> supported. The opensource-windows version can only be used from the
> place where you unpacked it (unless you rebuilt it in a new place).
>
> > You want to say, that qmake can't detect absolute qt installation path
> > without of hardcoding it o_0? Ha-ha. No, I don't saying that there is
> > pure-c++ way to detect it, but I convinced, that each OS provide a
> > simple way to detect application path.
>
> Uhm, its possible to have the libs in /usr/lib, the includes in
> /usr/include/qt4, the mkspecs in /usr/share/qt4/mkspecs and the bins in
> /opt/bin if you want (thats for linux, as I said for windows/opensource
> this whole discussion is moot because that version doesn't support
> installing). And qmake only knows /opt/bin it can't guess the rest of
> the paths. And then think about people that use symlinks, then /opt/bin
> might in fact be /usr/local/bin and if qmake would know that lib dir is
> in "../../usr/lib" it would fail because the absolute path it would know
> from the OS would be /usr/local/bin (i.e. no symlinks).
I have not much experience with *nix systems, but, AFAIK, this problem
is solved there by *.conf files, isn't it?
> Coding the installation path into the binary is IMHO perfectly fine and
> is being done with nearly any library I know - in some way or the other
> (think foo-config or pkg-config).
It should be a way to change installation path in simple way. Whether
it is a *.conf file or env-var. In a different way it is a design
fault.
> > > Apart from that: I've never seen designer or linguist needing Qt in a
> > > specific path, all those apps need is the qt libs besides them and
> > > eventually the plugins at a proper place (and that stuff is documented
> > > IIRC)
> >
> > What about windows? For example I want to place most of development
> > stuff onto CD/DVD.
> > There is documented drive letter for CD? Maybe, but computers, where I
> > have to develop my projects each have different letters for that
> > drive.
>
> I don't see a linux/unix-specific thing in my statement you quoted.
The thing is that in a *nix systems there is no notion "drive letter"
and all file access is based on paths that have only one root(/).
> Anyway, yes thats not supported by Qt if you don't have the same drive
> letter (well a OS with drive letters is broken anyway, but thats a
> different story ;). But win2k/winxp/vista can easily change the drive
> letter of the CD/DVD drive, thats a 5 minute job. Of course that imposes
> a problem if you don't work on that machine alone.
> OTOH it takes about 5
> minutes to install a Qt onto a PC and another 5 minutes when you need to
> do an update. Unless you're developing on some 3 dozen machines (in
> which case you've got other problems than just syncing Qt, but all the
> other software and you need some software distribution system anyway)
> thats not really a problem, IMHO.
That is the case that i need own-built Qt distribution and as you know
build-process is much long-duration.
> Just out of curiosity: Do you create/update your CD/DVD every 2 or 3
> months when TT releases a new Qt version?
I'm only trying to create this CD. If I'll solve all problems, than,
create/update process shouldn't be delivering headache.
> > > > it could even make it dependent on the environment variable. As Qt
> > > > uses QTDIR environment variable?
> > >
> > > No env vars are bad, because they force the user to set them up
> > > properly instead of qmake (just taking it as an example here) working
> > > out of the box. Apart from that: TT doesn't support QTDIR anymore with
> > > Qt4. It still does support QMAKESPEC to choose a different dir for the
> > > mkspecs.
> > >
> > > > 1. Please, remove all hardcoded paths from next releases.
> > >
> > > Won't happen I think. Apart from that: Wrong adress, this is about using
> > > Qt, not reporting bugs or feature wishes. Use the proper reporting
> > > channels.
> >
> > What channels? I found only xx-interest lists :(.
>
> Check the website, there are feedback channels for exactly this purpose.
> You're not even guaranteed that TT reads your email on this list,
> because this is not an official TT channel. Its more like a qt-users
> list.
>
> Andreas
>
> --
> That secret you've been guarding, isn't.
--
[ signature omitted ]
Message 6 in thread
On 26.08.07 17:53:45, Vadim Doroginin wrote:
> On 8/26/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> > Why should those be stored relative? You can't change qmake's
> > QT_INSTALL_PREFIX (IIRC) unless you recompile qmake. Apart from that the
> > opensource-windows version can't "install" anyway, thats simply not
> > supported. The opensource-windows version can only be used from the
> > place where you unpacked it (unless you rebuilt it in a new place).
> >
> > > You want to say, that qmake can't detect absolute qt installation path
> > > without of hardcoding it o_0? Ha-ha. No, I don't saying that there is
> > > pure-c++ way to detect it, but I convinced, that each OS provide a
> > > simple way to detect application path.
> >
> > Uhm, its possible to have the libs in /usr/lib, the includes in
> > /usr/include/qt4, the mkspecs in /usr/share/qt4/mkspecs and the bins in
> > /opt/bin if you want (thats for linux, as I said for windows/opensource
> > this whole discussion is moot because that version doesn't support
> > installing). And qmake only knows /opt/bin it can't guess the rest of
> > the paths. And then think about people that use symlinks, then /opt/bin
> > might in fact be /usr/local/bin and if qmake would know that lib dir is
> > in "../../usr/lib" it would fail because the absolute path it would know
> > from the OS would be /usr/local/bin (i.e. no symlinks).
>
> I have not much experience with *nix systems, but, AFAIK, this problem
> is solved there by *.conf files, isn't it?
No its not. Its completely up to the application to allow or disallow
this and deal with the problems that might arise when allowing such
things. Currently Qt under *nix doesn't allow to move the app.
> > Coding the installation path into the binary is IMHO perfectly fine and
> > is being done with nearly any library I know - in some way or the other
> > (think foo-config or pkg-config).
>
> It should be a way to change installation path in simple way. Whether
> it is a *.conf file or env-var. In a different way it is a design
> fault.
Not really, on unix you usually don't change installation paths and also
you don't really need to. The plain reason is that its way of dealing
with filesystems is non-broken. If you get a software that wants to be
place in /foo/some/stupid/path and you want it in $HOME/stupidapp, the
you just create
a) a proper symlink
b) a rebinding mountpoint
Done. The problem of moving apps around can be solved easily (quite the
same with your CD, there's no drive letter and even if the CD is mounted
under different paths you can make them look the same)
> > > > Apart from that: I've never seen designer or linguist needing Qt in a
> > > > specific path, all those apps need is the qt libs besides them and
> > > > eventually the plugins at a proper place (and that stuff is documented
> > > > IIRC)
> > >
> > > What about windows? For example I want to place most of development
> > > stuff onto CD/DVD.
> > > There is documented drive letter for CD? Maybe, but computers, where I
> > > have to develop my projects each have different letters for that
> > > drive.
> >
> > I don't see a linux/unix-specific thing in my statement you quoted.
>
> The thing is that in a *nix systems there is no notion "drive letter"
> and all file access is based on paths that have only one root(/).
Exactly, except that you can rename drive letters quite easily in
non-broken win32 systems (aka win2k and younger, I wouldn't even try
doing serious development with VC++6 on a win98/me box).
> > Anyway, yes thats not supported by Qt if you don't have the same drive
> > letter (well a OS with drive letters is broken anyway, but thats a
> > different story ;). But win2k/winxp/vista can easily change the drive
> > letter of the CD/DVD drive, thats a 5 minute job. Of course that imposes
> > a problem if you don't work on that machine alone.
>
> > OTOH it takes about 5
> > minutes to install a Qt onto a PC and another 5 minutes when you need to
> > do an update. Unless you're developing on some 3 dozen machines (in
> > which case you've got other problems than just syncing Qt, but all the
> > other software and you need some software distribution system anyway)
> > thats not really a problem, IMHO.
>
> That is the case that i need own-built Qt distribution and as you know
> build-process is much long-duration.
Huh? Ok, linux-build with gcc is a bit fast (takes about 45 minutes for
debug-only), but my rather old AMD 900MHz box here builds qt4.3 with
mingw in debug mode in about 1 hour - no examples of course, but who
needs all of them prebuilt anyway.
> > Just out of curiosity: Do you create/update your CD/DVD every 2 or 3
> > months when TT releases a new Qt version?
>
> I'm only trying to create this CD. If I'll solve all problems, than,
> create/update process shouldn't be delivering headache.
See the kdewin package for Qt, you should be able to just take the .zip
unpack it and change the qt.conf in it. Then all you'll have to do is
change the driver letter in the target system.
Andreas
--
[ signature omitted ]
Message 7 in thread
On Sunday 26 August 2007 15:10:32 Andreas Pakulat wrote:
> > > Coding the installation path into the binary is IMHO perfectly fine and
> > > is being done with nearly any library I know - in some way or the other
> > > (think foo-config or pkg-config).
> >
> > It should be a way to change installation path in simple way. Whether
> > it is a *.conf file or env-var. In a different way it is a design
> > fault.
>
> Not really, on unix you usually don't change installation paths and also
> you don't really need to. The plain reason is that its way of dealing
> with filesystems is non-broken.
Ease up a bit, please? Just because it isn't linux (well, unix, really)
doesn't mean it's the end of the world :) Windows drives me up a wall in 10
minutes top, too, but freedom of choice and all that, eh?
> If you get a software that wants to be
> place in /foo/some/stupid/path and you want it in $HOME/stupidapp, the
> you just create
>
> a) a proper symlink
> b) a rebinding mountpoint
I suppose. I have yet to do either, though. In any case, on linux, the package
manager takes care of all that.
>
> Done. The problem of moving apps around can be solved easily (quite the
> same with your CD, there's no drive letter and even if the CD is mounted
> under different paths you can make them look the same)
Huh? You can move apps around all you like, usually. libraries are more
tricky, as ldd needs to be able to find them.I think, but don't know, the
situation is much the same on win32.
> > The thing is that in a *nix systems there is no notion "drive letter"
> > and all file access is based on paths that have only one root(/).
>
> Exactly, except that you can rename drive letters quite easily in
> non-broken win32 systems (aka win2k and younger, I wouldn't even try
> doing serious development with VC++6 on a win98/me box).
Surely, there is a way to handle this issue under win32. All applications that
use dll's must have this problem, so there must be a solution. I wild guess:
You put the dlls in /windows/system or something, and the dll loader looks
there.
Sorry, I don't really have any answers. Only, I'm convinced there must be an
answer. I'd also be rather surprised of QT didn't play nice with the win32
environment, so I think it is just a matter of getting out the google-foo an
get searching :) Or wait till Monday, maybe some windownerds will chime in
how dynamic linking is supposed to resolve on windows.
--
[ signature omitted ]
Message 8 in thread
On 26.08.07 15:48:43, Esben Mose Hansen wrote:
> On Sunday 26 August 2007 15:10:32 Andreas Pakulat wrote:
> > > > Coding the installation path into the binary is IMHO perfectly fine and
> > > > is being done with nearly any library I know - in some way or the other
> > > > (think foo-config or pkg-config).
> > >
> > > It should be a way to change installation path in simple way. Whether
> > > it is a *.conf file or env-var. In a different way it is a design
> > > fault.
> >
> > Not really, on unix you usually don't change installation paths and also
> > you don't really need to. The plain reason is that its way of dealing
> > with filesystems is non-broken.
>
> Ease up a bit, please? Just because it isn't linux (well, unix, really)
> doesn't mean it's the end of the world :) Windows drives me up a wall in 10
> minutes top, too, but freedom of choice and all that, eh?
I didn't meant to say that win32 is total crap, but its way of dealing
with filesystems and binding new media into the system is IMHO just
plain broken. Those drive letters have no real meaning, its just
something that windows always had.
> > If you get a software that wants to be
> > place in /foo/some/stupid/path and you want it in $HOME/stupidapp, the
> > you just create
> >
> > a) a proper symlink
> > b) a rebinding mountpoint
>
> I suppose. I have yet to do either, though. In any case, on linux, the package
> manager takes care of all that.
No it doesn't. The package manager just installs a package and Qt4 would
still work when you remove those symlinks from /usr/share/qt4 (or
whatever your system distributor chose as "qt directory"). Simply
because qmake knows where its "parts" are in Qt4. Its different for Qt3
ad I think one reason to not have QTDIR anymore is because that makes it
impossible to have
/usr/lib
/usr/include/qt3
/usr/share/doc/qt3
/usr/bin
/usr/share/qt3/mkspecs
Without symlinks in /usr/share/qt3 for lib,bin, include and docs.
> > Done. The problem of moving apps around can be solved easily (quite the
> > same with your CD, there's no drive letter and even if the CD is mounted
> > under different paths you can make them look the same)
>
> Huh? You can move apps around all you like, usually. libraries are more
> tricky, as ldd needs to be able to find them.I think, but don't know, the
> situation is much the same on win32.
Thats not the case for QMake, it has the installation dir (or builddir
on win32) stored in its internals, though you can change that with a
proper qt.conf in the qt directory at least on win32. Don't know if
qt.conf works on linux/unix as well.
> > > The thing is that in a *nix systems there is no notion "drive letter"
> > > and all file access is based on paths that have only one root(/).
> >
> > Exactly, except that you can rename drive letters quite easily in
> > non-broken win32 systems (aka win2k and younger, I wouldn't even try
> > doing serious development with VC++6 on a win98/me box).
>
> Surely, there is a way to handle this issue under win32. All applications that
> use dll's must have this problem, so there must be a solution. I wild guess:
> You put the dlls in /windows/system or something, and the dll loader looks
> there.
Hell no. Thats the worst thing to do. And this is not really about
designer or linguist failing to find their dll's as Qt puts the dll's
into the bin/ folder where win32 linker will find them when you execute
the app. However its about building Qt apps with Qt moved to another
dir, which only works if you let Qt know where its installed now (on
win32 using qt.conf or rebuilding it, on linux I have no idea)
> Sorry, I don't really have any answers. Only, I'm convinced there must be an
> answer. I'd also be rather surprised of QT didn't play nice with the win32
> environment, so I think it is just a matter of getting out the google-foo an
> get searching :) Or wait till Monday, maybe some windownerds will chime in
> how dynamic linking is supposed to resolve on windows.
IMHO the opensource versions buildsystem for win32 is kinda crippled.
Its pretty obvious that it doesn't even allow to do a
configure -prefix c:\foobar
You'll always end up just configure'ing and then building with no
install at all. At least I didn't get an unpacked opensource qt4 to
even run qmake when specifying -prefix (its trying to search the mkspecs
in the install-location instead of the buildlocation).
Andreas
--
[ signature omitted ]
Message 9 in thread
> I didn't meant to say that win32 is total crap, but its way of dealing
> with filesystems and binding new media into the system is IMHO just
> plain broken. Those drive letters have no real meaning, its just
> something that windows always had.
Actually... It came from CPM -> DOS -> Windows....
I never found the drive system two bad...
>
> > > If you get a software that wants to be
> > > place in /foo/some/stupid/path and you want it in $HOME/stupidapp,
the
> > > you just create
> > >
> > > a) a proper symlink
> > > b) a rebinding mountpoint
> >
> > I suppose. I have yet to do either, though. In any case, on linux,
the
> package
> > manager takes care of all that.
>
> No it doesn't. The package manager just installs a package and Qt4
would
> still work when you remove those symlinks from /usr/share/qt4 (or
> whatever your system distributor chose as "qt directory"). Simply
> because qmake knows where its "parts" are in Qt4. Its different for
Qt3
> ad I think one reason to not have QTDIR anymore is because that makes
it
> impossible to have
>
> /usr/lib
> /usr/include/qt3
> /usr/share/doc/qt3
> /usr/bin
> /usr/share/qt3/mkspecs
>
> Without symlinks in /usr/share/qt3 for lib,bin, include and docs.
>
> > > Done. The problem of moving apps around can be solved easily
(quite
> the
> > > same with your CD, there's no drive letter and even if the CD is
> mounted
> > > under different paths you can make them look the same)
> >
> > Huh? You can move apps around all you like, usually. libraries are
more
> > tricky, as ldd needs to be able to find them.I think, but don't
know,
> the
> > situation is much the same on win32.
>
> Thats not the case for QMake, it has the installation dir (or builddir
> on win32) stored in its internals, though you can change that with a
> proper qt.conf in the qt directory at least on win32. Don't know if
> qt.conf works on linux/unix as well.
>
> > > > The thing is that in a *nix systems there is no notion "drive
> letter"
> > > > and all file access is based on paths that have only one
root(/).
> > >
> > > Exactly, except that you can rename drive letters quite easily in
> > > non-broken win32 systems (aka win2k and younger, I wouldn't even
try
> > > doing serious development with VC++6 on a win98/me box).
> >
> > Surely, there is a way to handle this issue under win32. All
> applications that
> > use dll's must have this problem, so there must be a solution. I
wild
> guess:
> > You put the dlls in /windows/system or something, and the dll loader
> looks
> > there.
>
> Hell no. Thats the worst thing to do. And this is not really about
> designer or linguist failing to find their dll's as Qt puts the dll's
> into the bin/ folder where win32 linker will find them when you
execute
> the app. However its about building Qt apps with Qt moved to another
> dir, which only works if you let Qt know where its installed now (on
> win32 using qt.conf or rebuilding it, on linux I have no idea)
YAH... the win32 .dll loader has very specific rules on how to load the
DLL...
First, local dir of the calling app, second the working dir of the
calling app, third the system dir, then the windows dir, then the path
variable path
For system dlls there is a method for setting which exact one to pick up
(so there is no cross contamination)...
>
> > Sorry, I don't really have any answers. Only, I'm convinced there
must
> be an
> > answer. I'd also be rather surprised of QT didn't play nice with the
> win32
> > environment, so I think it is just a matter of getting out the
google-
> foo an
> > get searching :) Or wait till Monday, maybe some windownerds will
chime
> in
> > how dynamic linking is supposed to resolve on windows.
>
> IMHO the opensource versions buildsystem for win32 is kinda crippled.
> Its pretty obvious that it doesn't even allow to do a
>
> configure -prefix c:\foobar
>
> You'll always end up just configure'ing and then building with no
> install at all. At least I didn't get an unpacked opensource qt4 to
> even run qmake when specifying -prefix (its trying to search the
mkspecs
> in the install-location instead of the buildlocation).
>
> Andreas
Yep... and not just building the open source version, I have never been
successful of building, using configure, the source tree to where I want
it two.
That said, there is a huge difference of putting the burden of hard
coded install paths on a developer (which I personally hate) and putting
that burden on a CLOSED SOURCE distribution system.
Say you have a custom app, with a custom setup of QT... it's a closed
source unix app. And it needs the plugin system... (ie no static
linking)
Maybe you have some custom code you don't want to poisen a machine so
you want to put the .so's in the distribution location...
And you DON'T know the location that a CUSTOMER wants to put it.
Frankly... I hate binary files with fixed paths... that's what
LD_LIBRARY_PATH is for.
Scott
--
[ signature omitted ]
Message 10 in thread
On 26.08.07 18:29:51, Scott Aron Bloom wrote:
> That said, there is a huge difference of putting the burden of hard
> coded install paths on a developer (which I personally hate) and putting
> that burden on a CLOSED SOURCE distribution system.
>
> Say you have a custom app, with a custom setup of QT... it's a closed
> source unix app. And it needs the plugin system... (ie no static
> linking)
>
> Maybe you have some custom code you don't want to poisen a machine so
> you want to put the .so's in the distribution location...
>
> And you DON'T know the location that a CUSTOMER wants to put it.
>
>
> Frankly... I hate binary files with fixed paths... that's what
> LD_LIBRARY_PATH is for.
Well, thats all not a problem here. We're not talking about designer,
uic, moc, (not sure if these two link dynamically), linguist or any
other Qt executable (that links dynamically against Qt). All these don't
(at least to my knowledge) have the dll-location hardcoded - I'll fire
up my win32 system later today, its definetly not the case on *nix.
The only place where AFAIK absolute paths are stored is inside qmake
(which you can query using for example qmake -query QT_INSTALL_PATH),
for anybody wondering what else you can query see
http://wiki.qtcentre.org/index.php?title=Undocumented_qmake
However these hardcoded paths only come into play when you _build_ your
Qt application. Which probably a consumer doesn't do for closed-source
apps. For those you'll just have to make sure your app carries the
shared libs and plugins in the right place (dll's in the app dir,
plugins in plugins subdir in proper hierarchy on win32).
And thats why I don't really see the problem of having these paths
hardcoded into qmake (especially as they can be influenced by a proper
qt.conf file in the qt dir).
Andreas
--
[ signature omitted ]
Message 11 in thread
On 08-27-2007 1:16 AM, "Andreas Pakulat" wrote:
> Well, thats all not a problem here. We're not talking about designer,
> uic, moc, (not sure if these two link dynamically), linguist or any
> other Qt executable (that links dynamically against Qt). All these don't
> (at least to my knowledge) have the dll-location hardcoded - I'll fire
> up my win32 system later today, its definetly not the case on *nix.
>
> The only place where AFAIK absolute paths are stored is inside qmake
> (which you can query using for example qmake -query QT_INSTALL_PATH),
> for anybody wondering what else you can query see
> http://wiki.qtcentre.org/index.php?title=Undocumented_qmake
>
> However these hardcoded paths only come into play when you _build_ your
> Qt application. Which probably a consumer doesn't do for closed-source
> apps. For those you'll just have to make sure your app carries the
> shared libs and plugins in the right place (dll's in the app dir,
> plugins in plugins subdir in proper hierarchy on win32).
>
> And thats why I don't really see the problem of having these paths
> hardcoded into qmake (especially as they can be influenced by a proper
> qt.conf file in the qt dir).
>
> Andreas
If qmake is the only thing that has static paths stored, then it is EASY to
fix (for Trolltech). Since the location of qmake is in $QTDIR/bin, it is
always relative to QTDIR (..), the library path (../lib), the plugins path
(../plugins), etc. THAT is the way it should be stored inside of qmake.
Then it becomes simple to move the Qt directory anywhere the user
(developer) needs to move it without requiring a rebuild. I have needed to
move QTDIR on several occasions on Windows because of disk space
requirements. It is a royal pain to have to rebuild everything (90 minutes
or more) when all I did was relocate a folder and change $QTDIR to point to
the new location.
Anything else that has static paths can (and should) be fixed in the same
way.
Of course, there are other Qt applications that have similar issues. In
particular, Assistant should let me pick WHICH (current or earlier) version
of the documentation I want to look at (4.3.1, 4.3.0, 4.2.3, etc.).
Keith
**Please do not reply to me, reply to the list.**
--
[ signature omitted ]
Message 12 in thread
On 27.08.07 11:22:06, Keith Esau wrote:
> On 08-27-2007 1:16 AM, "Andreas Pakulat" wrote:
>
> > Well, thats all not a problem here. We're not talking about designer,
> > uic, moc, (not sure if these two link dynamically), linguist or any
> > other Qt executable (that links dynamically against Qt). All these don't
> > (at least to my knowledge) have the dll-location hardcoded - I'll fire
> > up my win32 system later today, its definetly not the case on *nix.
> >
> > The only place where AFAIK absolute paths are stored is inside qmake
> > (which you can query using for example qmake -query QT_INSTALL_PATH),
> > for anybody wondering what else you can query see
> > http://wiki.qtcentre.org/index.php?title=Undocumented_qmake
> >
> > However these hardcoded paths only come into play when you _build_ your
> > Qt application. Which probably a consumer doesn't do for closed-source
> > apps. For those you'll just have to make sure your app carries the
> > shared libs and plugins in the right place (dll's in the app dir,
> > plugins in plugins subdir in proper hierarchy on win32).
> >
> > And thats why I don't really see the problem of having these paths
> > hardcoded into qmake (especially as they can be influenced by a proper
> > qt.conf file in the qt dir).
>
> If qmake is the only thing that has static paths stored, then it is EASY to
> fix (for Trolltech). Since the location of qmake is in $QTDIR/bin, it is
> always relative to QTDIR (..), the library path (../lib), the plugins path
> (../plugins), etc. THAT is the way it should be stored inside of qmake.
Thats how it is on win32, because you can't use the various switches of
configure (the shell script). On *nix you can distribute your Qt into
various places (as I said earlier, /usr/bin, /usr/lib, /usr/include/qt4,
/usr/share/qt4/mkspecs, /usr/lib/qt4/plugins and so on). Thats why its
easier for qmake to record the absolute path. Of course it could also
record a bunch of relative paths to the installation directory and store
just the install dir in an absolute form or do various computations
based on its own location.
> Then it becomes simple to move the Qt directory anywhere the user
> (developer) needs to move it without requiring a rebuild. I have needed to
> move QTDIR on several occasions on Windows because of disk space
> requirements. It is a royal pain to have to rebuild everything (90 minutes
> or more) when all I did was relocate a folder and change $QTDIR to point to
> the new location.
As I tried to explain earlier in the thread: On win32 you don't have to
do any rebuilding when you use a qt.conf in the Qt dir. QMake will use
the values therein, for more information how that file looks like see
the Qt packages delivered by the kdewin-installer (don't have a url at
hand, sorry)
> Of course, there are other Qt applications that have similar issues. In
> particular, Assistant should let me pick WHICH (current or earlier) version
> of the documentation I want to look at (4.3.1, 4.3.0, 4.2.3, etc.).
I can completely agree with that. Although I never use assistant for
browsing the docs, a webbrowser works 100 times better (except for the
search-stuff maybe).
Andreas
--
[ signature omitted ]
Message 13 in thread
[snip]
> because qmake knows where its "parts" are in Qt4. Its different for Qt3
> ad I think one reason to not have QTDIR anymore is because that makes it
> impossible to have
[snip]
Please,
don't even think about something like $QTDIR! Environment variables are
like hell (especially on windows). Have you ever tried to use several
versions of a software using env vars in parallel on one machine? It was
one of the best decisions of TT to remove QTDIR when switching from Qt3 to
Qt4.
And besides that - think about the "namespace hell" between software
products ...
Don't get me wrong - I love env vars - but _NOT_ as needed part of
software installations.
Regards,
Malte
--
[ signature omitted ]
Message 14 in thread
On Sunday 26 August 2007 16:25:07 Andreas Pakulat wrote:
grrr, resend with correct email address, sorry for the delay.
> On 26.08.07 15:48:43, Esben Mose Hansen wrote:
> > On Sunday 26 August 2007 15:10:32 Andreas Pakulat wrote:
> > Ease up a bit, please? Just because it isn't linux (well, unix, really)
> > doesn't mean it's the end of the world :) Windows drives me up a wall in
> > 10 minutes top, too, but freedom of choice and all that, eh?
>
> I didn't meant to say that win32 is total crap, but its way of dealing
> with filesystems and binding new media into the system is IMHO just
> plain broken. Those drive letters have no real meaning, its just
> something that windows always had.
I know. Actually, I hear it is possible to mount filesystems into another on
windows these days, so maybe there is hope. Still, insulting the other guys
filesystem might not be the best approach :)
>
> > > Done. The problem of moving apps around can be solved easily (quite the
> > > same with your CD, there's no drive letter and even if the CD is
> > > mounted under different paths you can make them look the same)
> >
> > Huh? You can move apps around all you like, usually. libraries are more
> > tricky, as ldd needs to be able to find them.I think, but don't know, the
> > situation is much the same on win32.
>
> Thats not the case for QMake, it has the installation dir (or builddir
> on win32) stored in its internals, though you can change that with a
> proper qt.conf in the qt directory at least on win32. Don't know if
> qt.conf works on linux/unix as well.
Well, yeah, but that's a qmake issue. Presumably, he wouldn't need qmake ones
he has build his program. If, on the other hand, he is distributing source,
he can just tell people to grab & compile qt, as appropriate. It's just qmake
that is doing double duty as pkg-config, really.
>
> > > > The thing is that in a *nix systems there is no notion "drive letter"
> > > > and all file access is based on paths that have only one root(/).
> > >
> > > Exactly, except that you can rename drive letters quite easily in
> > > non-broken win32 systems (aka win2k and younger, I wouldn't even try
> > > doing serious development with VC++6 on a win98/me box).
> >
> > Surely, there is a way to handle this issue under win32. All applications
> > that use dll's must have this problem, so there must be a solution. I
> > wild guess: You put the dlls in /windows/system or something, and the dll
> > loader looks there.
>
> Hell no. Thats the worst thing to do. And this is not really about
> designer or linguist failing to find their dll's as Qt puts the dll's
> into the bin/ folder where win32 linker will find them when you execute
> the app. However its about building Qt apps with Qt moved to another
> dir, which only works if you let Qt know where its installed now (on
> win32 using qt.conf or rebuilding it, on linux I have no idea)
ok, so this is really about the build system qmake? In that case my suggested
solution is: don't use qmake. Use cmake :) qmake will only be used to
autodetect the QT installation. And that autodetection can be overruled, no
problem.
>
> > Sorry, I don't really have any answers. Only, I'm convinced there must be
> > an answer. I'd also be rather surprised of QT didn't play nice with the
> > win32 environment, so I think it is just a matter of getting out the
> > google-foo an get searching :) Or wait till Monday, maybe some
> > windownerds will chime in how dynamic linking is supposed to resolve on
> > windows.
>
> IMHO the opensource versions buildsystem for win32 is kinda crippled.
> Its pretty obvious that it doesn't even allow to do a
>
> configure -prefix c:\foobar
>
> You'll always end up just configure'ing and then building with no
> install at all. At least I didn't get an unpacked opensource qt4 to
> even run qmake when specifying -prefix (its trying to search the mkspecs
> in the install-location instead of the buildlocation).
OK. I almost never use qmake, as I much prefer cmake. I didn't catch that you
were discussing qmake, I just thought I'd smooth the waters a bit.
--
[ signature omitted ]
Message 15 in thread
On 27.08.07 11:29:48, Esben Mose Hansen wrote:
> On Sunday 26 August 2007 16:25:07 Andreas Pakulat wrote:
> > On 26.08.07 15:48:43, Esben Mose Hansen wrote:
> > > On Sunday 26 August 2007 15:10:32 Andreas Pakulat wrote:
> > > > > The thing is that in a *nix systems there is no notion "drive letter"
> > > > > and all file access is based on paths that have only one root(/).
> > > >
> > > > Exactly, except that you can rename drive letters quite easily in
> > > > non-broken win32 systems (aka win2k and younger, I wouldn't even try
> > > > doing serious development with VC++6 on a win98/me box).
> > >
> > > Surely, there is a way to handle this issue under win32. All applications
> > > that use dll's must have this problem, so there must be a solution. I
> > > wild guess: You put the dlls in /windows/system or something, and the dll
> > > loader looks there.
> >
> > Hell no. Thats the worst thing to do. And this is not really about
> > designer or linguist failing to find their dll's as Qt puts the dll's
> > into the bin/ folder where win32 linker will find them when you execute
> > the app. However its about building Qt apps with Qt moved to another
> > dir, which only works if you let Qt know where its installed now (on
> > win32 using qt.conf or rebuilding it, on linux I have no idea)
>
> ok, so this is really about the build system qmake? In that case my suggested
> solution is: don't use qmake. Use cmake :) qmake will only be used to
> autodetect the QT installation. And that autodetection can be overruled, no
> problem.
Well the OP claims that there are paths stored in the other executables
which makes them unusable. But thats plain wrong. Yes there is another
path always stored somewhere in the apps: The plugin installation path
for Qt. However you can always add new paths to search for plugins using
an environment variable, just as the API docs in
QCoreApplication::libraryPaths() say. So the only real issue with
"hardcoded paths in Qt executables" can be qmake when used for the
buildsystem.
BTW: I do use cmake as well, but only for real projects. If I need to do
a small test app for something (probably just a main.cpp) its sooo much
easier to just run qmake -project;qmake;make and be done with it :)
Andreas
--
[ signature omitted ]
Pages: Prev | 1 | 2 | 3 | Next
