Pages

Sunday, February 28, 2016

Building IBPP on MinGW-w64

When building IBPP on MinGW-w64 MinGW complains that "Only Win32 is supported." Hey, I'm on Windows and we're building a Win32 executable!

But well, don't forget we're using an open source project and we're free to review the source code. Let's see _ibpp.h to find out why:
#if (defined(__GNUC__) && defined(IBPP_WINDOWS))
// UNSETTING flags used above for ibase.h -- Huge conflicts with libstdc++ !
#undef _MSC_VER
#undef _WIN32
#endif
As you see, if the compiler is found to be MinGW it #undefs _WIN32. It seems to be because of the compatibility against MinGW 3.0, yet in MinGW-w64 this is the very reason to block the "normal" build.

Hope this would help any Firebird users, who want to use it with IBPP under MinGW-w64.

P.S:
For relations and differences between MinGW and MinGW-w64, please refer to the URLs below:
https://sourceforge.net/p/mingw-w64/wiki2/History/
https://sourceforge.net/p/mingw-w64/wiki2/Feature%20list/

IBPP를 MinGW-w64에서 빌드하려면......

IBPP를 MinGW-w64에서 빌드하려면 갑자기 MinGW가 "Only Win32 is supported!"라는 에러를 내보내면서 빌드가 멈춥니다. Windows에서 빌드하는게 맞는데 Win32만 지원한다면서 투덜대면 이것도 참 황당한데요......

IBPP의 _ibpp.h를 보면 그 원인을 찾을 수 있습니다.
#if (defined(__GNUC__) && defined(IBPP_WINDOWS))
// UNSETTING flags used above for ibase.h -- Huge conflicts with libstdc++ !
#undef _MSC_VER
#undef _WIN32#endif
컴파일러가 MinGW라고 판단되는 경우 _WIN32를 undef하는 것을 보실 수 있습니다. 아마도 MinGW 3.0의 호환성 문제때문에 이렇게 설정한 것 같은데, MinGW-w64에서는 이 구문이 역으로 빌드를 막는 원인이 되는 듯 합니다.

국내에 Firebird를 쓰는 분들, 특히나 IBPP를 MinGW환경에서 사용하실 분들이 몇 분이나 되실지는 모르겠지만, 참고가 되셨으면 합니다.

P.S:
MinGW와 MinGW-w64 프로젝트의 관계 및 차이점에 대해서는 아래의 URL을 참고하세요:
https://sourceforge.net/p/mingw-w64/wiki2/History/
https://sourceforge.net/p/mingw-w64/wiki2/Feature%20list/

Wednesday, November 11, 2015

Tuesday, October 20, 2015

windeployqt를 이용하여 Qt Quick Controls 기반의 application을 packaging할 때의 주의점

Qt 5.5에서 windeployqt를 사용하여 Qt Quick Controls 기반의 application에 대한 packaging을 수행할 경우, PrivateWidgets 부분을 가져오지 못해 타 시스템에서는 UI가 보이지 않는 문제점이 있습니다.

이 문제를 해결하기 위해서는 Qt의 qml\QtQuick\PrivateWidgets 폴더를 패키지 디렉토리의 상응하는 위치로 복사해 주어야 합니다. (e.g. deployment\QtQuick\PrivateWidgets)


Qt Quick Control을 쓰시는 분들께 도움이 되시기 바랍니다.

Cautions on using windeployqt on Qt Quick Controls based applications

When packaging applications using windeployqt in Qt 5.5, you may experience the application doesn't show the interface because windeployqt doesn't recognize links to PrivateWidgets.

To solve the problem, copy qml\QtQuick\PrivateWidgetsfolder in Qt to respective location in deployment folder(e.g. deployment\QtQuick\PrivateWidgets).

Hope this helps those working with Qt Quick Controls.

Friday, September 4, 2015

On site development and Qt

Recently I had a chance to develop some applications on site. I used the greatly-productive Qt and Qt Creator, Application was built in an instant, and result was satisfactory. But the experience remained me some uncomfortable memory.

Except for skeleton codes, I put only 10 to 20 lines. I had to find out DLLs with more than 20MB, put them all to USB thumb drive, and I put the drive to PCs here and there. In each run I had to wait for 2~3 seconds more after starting running, and the delay became a burden as I repeated the job.

On Windows, Qt initiates DirectX and OpenGL, regardless of whether those modules are actually used in the application of not. My application was based fully on Qt Widgets and GDI, so that there's no way DirectX or OpenGL would be involved, but Qt initialized those stuff anyway. And to initialize, you have to wait for two or three seconds. If your system was already using those that's no problem, but in office environment, chances are that they'll be used only when you play video games, avoiding eyes of your boss.

Of course if the application is big enough to show splash screen saying "WAIT!" waiting for two or three seconds is no problem, but for apps quickly developed on site and run instantly, it's like forever - when you're busy and quick-tempered, chances are that you hit enter key a lot of times, resulting in starting a lot of instances at once, delaying the actual start more than ever(well, sometimes you experience Windows eats your keyboard or mouse input. don't you?).

Nowadays I feel that the high productivity and abundant features of Qt has its own tradeoff - e.g. performance issue(not only startup time, but also performance of features, like QLinkedList against similar others) and shared library. Of course in Linux the situation can be different, but in Windows it has its own story(if you're a GTK user that's yet another different story, but it's out of scope as for now).

Anyway, after experiencing this and that, I moved again from Qt to wxWidgets. I love the instant startup at cold start and freely available static link thanks to its license policy, resulting in easier deployment. There are, of course, some(expected) productivity losses or features not existing, but it can be overcome with the power of will(.....) and my own development.

I don't want to open the flame - Qt is really a great product and I totally agree. But there's no such thing as one size that fits to all. For some time being, I'll have fun with my wxWidgets and Code::Blocks.