[Eric] Re: Simplified installation?

[Andreas Pakulat]

On 26.06.07 14:47:57, techtonik wrote:
> Andreas Pakulat <apaku at ...> writes:
> 
> > First of all: This is the wrong list for this stuff, please use the pyqt
> > mailinglist for things that are related to building pyqt.
> 
> I do not need neither Qt, nor PyQT - everything I need is to see if Eric is
> better than PyDev. Considering the need to compile the code I thought that Eric
> could need some specific PyQT build requirements, so compiling PyQT by
> smb.elses' instructions could lead to problems similar to those I had trying to
> run pygtk with GTK+ installed from GIMP for Windows package.

Then how exactly do you find out how to build PyQt? Sorry, that doesn't
make the slightest sense to me.

Anyway, you should direct any problems you have with building PyQt to
the pyqt mailinglist.

> > Apart from that: MinGW only has gcc selected by default (IIRC), so you
> > as well need to add g++ already.  Why is it a problem to also having to
> > add make?
> 
> Because it wasn't mentioned anywhere.

Right, because normally you'd download the Qt binary package, which
comes with mingw on board.

> > > Well, the last message was due to the absence of Qt4Core.dll in PATH.
> > > Added it as well, but isn't it qmake what should have added it
> > > automatically? 
> > 
> > No, why should qmake fiddle with your path? I don't know how the binary
> > Qt package is laid out, but I guess its bin/ dir contains the dll's, so
> > all you have to do is adding the bin/ dir to PATH (which is AFAIK what
> > the Entry in the Qt/Trolltech menu does)
> 
> I've never used Qt up to this moment and learning it just to be able to use
> Python editor is an overkill.

Eric is _not_ a Python Editor.

> I could add bin/ to PATH earlier when I run in
> qmake.exe problem, but I was asked to specify path to qmake.exe explicitly via
> cmdline parameters, so I could hope that it will find all the rest by itself.

qmake normally finds everything it needs itself, however the application
that uses Qt (or library) needs to find the dll's and those need to be
in PATH. Thats a standard windows requirement.

> > > Now the famous QMAKE_CFLAGS_THREAD. I doesn't seem that patching Qt4 is a
> > > good idea, but there is no other choice so far.
> > 
> > Why is patching Qt4 not a good idea? Its the easiest workaround. You may
> > of course also fix PyQt and send a patch to the pyqt mailinglist so Phil
> > doesn't need to find the right way to handle this.
> 
> Because I haven't used to patching my developer's instruments like gcc or MinGW
> to compile anything. Why do I need to know all the bloody unix/make/c++ details
> if I program Python on windows? =/

Because you want to build everything from scratch instead of using the
existing binary packages. Also IIRC thats what is proposed on the PyQt
homepage.

> > Unfortunately I have to say that eric4 is close to unusable in parts on
> > win32. The tree views are dead-slow on opening/closing branches, while
> > they're fine in plain C++ apps and on linux.
> 
> I still would like to give it a try. PyDev is the only debugger I could use,
> but it is too crippled.

See the PyQt homepage, Phil recently uploaded a binary package that has
PyQt, QScintilla and IIRC also Qt bundled. Its for Python 2.5 though, so
you'd have to get that first.

Andreas

-- 
Don't worry.  Life's too long.
		-- Vincent Sardi, Jr.