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

[Mark Brand]

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
> 'mkspecs/glibc-g++'

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.

regards,

Mark