<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Phil Thompson wrote:
<blockquote cite="mid:e1711f744c02452fa3668229412c74e4@localhost"
type="cite">
<pre wrap="">On Thu, 11 Mar 2010 09:13:27 -0500, Josh <a class="moz-txt-link-rfc2396E" href="mailto:jknox@irobot.com"><jknox@irobot.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Phil Thompson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 10 Mar 2010 16:49:13 -0500, Josh <a class="moz-txt-link-rfc2396E" href="mailto:jknox@irobot.com"><jknox@irobot.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
In my dev environment we build packages of Qt, PyQt, SIP, etc on a
"central" build machine. Developers use these packages as dependencies
for their projects on their own machines. The packages are always
installed in different locations than where they were originally built.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">This leads to a problem where the plethora of paths specified in
pyqtconfig.sipconfig._config_stack all refer to the original build
machine. So, without some customization, its impossible to build
PyQt/SIP wrappers for our Qt C++ widgets.
My question is this: Is it correct to just pilfer through the elements
of pyqtconfig.sipconfig._config_stack and set things up for my system
(ie. string replace)?
</pre>
</blockquote>
<pre wrap="">No - _config_stack is an internal implementation detail.
</pre>
<blockquote type="cite">
<pre wrap="">Doing that just feels wrong. Is there a better way
to go about this?
</pre>
</blockquote>
<pre wrap="">No - what you are doing is simply unsupported.
Phil
</pre>
</blockquote>
<pre wrap="">OK, that's fine. I faced similar issues integrating Qt with our build
system. Just so I understand, are the official PyQt releases
built/installed into the exact same paths that are expected to be used
by end users?
</pre>
</blockquote>
<pre wrap=""><!---->
Of course, why would it be otherwise? Or have I misunderstood the question?
Phil
</pre>
</blockquote>
I realize that my situation is not typical, so this being unsupported
is OK. This isn't the first tool to require some massaging to work with
our system. Our build system packages numerous 3rd party/open source
tools into separate runtime & development packages, for various
target platforms. During development we may have projects with
dependencies on different versions of tools, so all compile time stuff
is installed locally in a sandbox. This gives us a clearly delineated
tool-chain for each specific project and target. <br>
<br>
This is fine for strictly header/library stuff, but with Qt/PyQt there
are tools that need to be run during development (qmake, sip, moc,
etc). Since these are initially built and packaged on one machine and
installed on another in different locations, the "hard coded" paths are
problematic. For instance, I cant just set the PATH, PYTHONPATH, etc to
point to the tools in a sandbox since the sipconfig module references
paths to the original build system. <br>
<br>
Qt provides support for this type of customization with qmake.conf,
overriding the original build paths embedded in qmake. Their package
installer even uses a patch mechanism (qpatch) to rummage
through the installed binaries and replace their build system paths
with the paths where Qt gets installed the end users' systems. I was
hoping there was something like that for PyQt, like "sipconfig.conf" or
something, that would allow me to customize the paths used by sip when
generating makefiles.<br>
<br>
That make sense? <br>
<br>
I'll gladly hack away to make it work for our environment, but any
ideas or suggestions are welcome.<br>
<br>
Thanks,<br>
<br>
Josh
</body>
</html>