[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mingw-cross-env-list] Re: Qt on Debian/kFreeBSD

From: Mark Brand
Subject: [Mingw-cross-env-list] Re: Qt on Debian/kFreeBSD
Date: Sun, 20 Mar 2011 22:52:26 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8

Hi Tony,

I've been working on getting Debian/kFreeBSD running and have a
question about ./configure in qt.

Sounds like a nice project and it raises some interesting issues.

The Debian build system [1] copies 'mkspecs/linux-g++' to

It looks like they found the linux-g++ mkspec well-suited to non-linux gnu/unix, but the mkspec name itself was a problem because it enables linux-specific code in the .pr[io] files.

  and then deletes the include directory:
     # Remove include directory. Then ./configure will take care of calling
     # syncqt and regenerating it.
     rm -rf include
At the moment, I'm wrapping this in:

     [ `uname -s` = 'GNU/kFreeBSD' ]&&  \
     cp -a '$(1)/mkspecs/linux-g++' '$(1)/mkspecs/glibc-g++'&&  \
     rm -rf '$(1)/include'
     cd '$(1)'&&  \ ...etc

Do I need to worry about only doing this conditionally? The copy wont
affect any other systems, but will deleting and re-generating the
include directory have any impact?
If deleting the include dir isn't something we want to do across the
board, is the

[ `uname -s` = 'GNU/kFreeBSD' ]&&

test a good approach, or should I patch configure in some way to
delete it

Are you sure we really need to call (or induce) syncqt? Adding a mkspec does not require this. Maybe Debian had or used to have patches that made it necessary to run syncqt. We used to have to call syncqt in mingw-cross-env and I think that was caused by our patches to the .pr[io] files which have since been included upstream.

But to answer your question, there should be no harm in unnecessarily running syncqt except wasted time. Up till now we've avoided tests for specific systems in the .mk files, so wasting a little time might not be so bad.

Volker might have a view about using 'uname -s' or some other technique if it comes to that.

(I'm already patching it to detect the platform [2])?

There is something to be said for *not* patching the configure script (or .pr[io] files) with references to ad hoc mkspecs. But the alternative of resorting to the -platform option in the .mk file for just this case would be messy and arguably worse.

The cleanest solution would be to get a mkspec and related configure support merged upstream. "Include" directives can be used to derive the new mkspec files (qmake.conf and qplatformdefs.h) from existing files.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]