extronus
22nd August 2010, 07:03
Hi,
I have a mid scale project which i recently decided to move from lumbering netbeans to qtcreator and change the build system to qmake. It consists of a core library, a gui library, various tests and executables.
Directory structure goes like this
libcore
string.h
signal.h
a.h
b.h
a.cpp
b.cpp
libgui
widget_a.h
widget_a.cpp
form_a.ui
form_a.h
form_a.cpp
form_b.ui
form_b.h
form_b.cpp
tests and executables
test directory
test_a.h
test_a.cpp
executable directory
exe_a.h
exe_a.cpp
As you can see, i have some header names like "string.h" and "signal.h" and because of that, when a library is built, it is supposed to go into build directory like this.
build_direcotory
include
tbs
string.h
signal.h
widget_a.h
ui_widget_a.h // Generated as result of uic causes directory
// to be added to include path
etc...
lib
libcore.a
To achieve this, i have an pri file and a function in it. (macro / test ?)
which does configuration _almost_ correctly
# ----------------------------------------------------------------------------
header_copy.input = HEADERS
header_copy.commands = @$$QMAKE_COPY ${QMAKE_FILE_NAME} ${QMAKE_FILE_OUT}
header_copy.output = ../include/tbs/${QMAKE_FILE_BASE}.h
# ----------------------------------------------------------------------------
defineTest(configuration) {
target_name = $$1
target_type = $$2
output_directory = $$3
TARGET = $$target_name
INCLUDEPATH = $$output_directory/include
LIBS += -L$$output_directory/lib
contains(target_type, lib) {
TEMPLATE = lib
CONFIG += staticlib
DESTDIR = $$output_directory/lib
UI_DIR = $$output_directory/obj/ui
#UI_HEADERS_DIR = $$output_directory/include/tbs
QMAKE_EXTRA_COMPILERS += header_copy
}
else:contains(target_type, exe) {
DESTDIR = $$output_directory/bin
TEMPLATE = app
debug {
CONFIG += console
}
}
export(TARGET)
export(TEMPLATE)
export(CONFIG)
export(DESTDIR)
export(UI_DIR)
export(UI_HEADERS_DIR)
export(INCLUDEPATH)
export(LIBS)
export(HEADERS)
export(QMAKE_EXTRA_COMPILERS)
}
Which is called from each "pro" file like this
include (../tbs_desktop.pri)
configuration(tbs, lib, ..)
This does most of the job as intended. However the commented out line which places generated headers to their correct place, also adds that directory to include path. Resulting headers like "string.h" and "signal.h" to be included from standart library and Qt in place of intended headers. Creating a thousand lines long compile time mess. :)
I've tried :
INCLUDEPATH -= $$UI_HEADERS_DIR
which had no effect, and attempted to replace command that executes uic with
# ----------------------------------------------------------------------------
UIC.input = FORMS
UIC.commands = @$$QMAKE_UIC ${QMAKE_FILE_NAME} -o ../include/tbs/${QMAKE_FILE_BASE}.h && echo ehore
UIC.output = ../include/tbs/${QMAKE_FILE_BASE}.h
QMAKE_EXTRA_COMPILERS += UIC
but this created another mess.
Is there a way to prevent UI_HEADERS_DIR from being added to include path or any other way to work around this issue?
* autotools is not an option as it is not really cross platform. (it requires a full blown unix environment to work)
* CMake is an option but it requires re-write of build system and i'm a total newbie to it.
I have a mid scale project which i recently decided to move from lumbering netbeans to qtcreator and change the build system to qmake. It consists of a core library, a gui library, various tests and executables.
Directory structure goes like this
libcore
string.h
signal.h
a.h
b.h
a.cpp
b.cpp
libgui
widget_a.h
widget_a.cpp
form_a.ui
form_a.h
form_a.cpp
form_b.ui
form_b.h
form_b.cpp
tests and executables
test directory
test_a.h
test_a.cpp
executable directory
exe_a.h
exe_a.cpp
As you can see, i have some header names like "string.h" and "signal.h" and because of that, when a library is built, it is supposed to go into build directory like this.
build_direcotory
include
tbs
string.h
signal.h
widget_a.h
ui_widget_a.h // Generated as result of uic causes directory
// to be added to include path
etc...
lib
libcore.a
To achieve this, i have an pri file and a function in it. (macro / test ?)
which does configuration _almost_ correctly
# ----------------------------------------------------------------------------
header_copy.input = HEADERS
header_copy.commands = @$$QMAKE_COPY ${QMAKE_FILE_NAME} ${QMAKE_FILE_OUT}
header_copy.output = ../include/tbs/${QMAKE_FILE_BASE}.h
# ----------------------------------------------------------------------------
defineTest(configuration) {
target_name = $$1
target_type = $$2
output_directory = $$3
TARGET = $$target_name
INCLUDEPATH = $$output_directory/include
LIBS += -L$$output_directory/lib
contains(target_type, lib) {
TEMPLATE = lib
CONFIG += staticlib
DESTDIR = $$output_directory/lib
UI_DIR = $$output_directory/obj/ui
#UI_HEADERS_DIR = $$output_directory/include/tbs
QMAKE_EXTRA_COMPILERS += header_copy
}
else:contains(target_type, exe) {
DESTDIR = $$output_directory/bin
TEMPLATE = app
debug {
CONFIG += console
}
}
export(TARGET)
export(TEMPLATE)
export(CONFIG)
export(DESTDIR)
export(UI_DIR)
export(UI_HEADERS_DIR)
export(INCLUDEPATH)
export(LIBS)
export(HEADERS)
export(QMAKE_EXTRA_COMPILERS)
}
Which is called from each "pro" file like this
include (../tbs_desktop.pri)
configuration(tbs, lib, ..)
This does most of the job as intended. However the commented out line which places generated headers to their correct place, also adds that directory to include path. Resulting headers like "string.h" and "signal.h" to be included from standart library and Qt in place of intended headers. Creating a thousand lines long compile time mess. :)
I've tried :
INCLUDEPATH -= $$UI_HEADERS_DIR
which had no effect, and attempted to replace command that executes uic with
# ----------------------------------------------------------------------------
UIC.input = FORMS
UIC.commands = @$$QMAKE_UIC ${QMAKE_FILE_NAME} -o ../include/tbs/${QMAKE_FILE_BASE}.h && echo ehore
UIC.output = ../include/tbs/${QMAKE_FILE_BASE}.h
QMAKE_EXTRA_COMPILERS += UIC
but this created another mess.
Is there a way to prevent UI_HEADERS_DIR from being added to include path or any other way to work around this issue?
* autotools is not an option as it is not really cross platform. (it requires a full blown unix environment to work)
* CMake is an option but it requires re-write of build system and i'm a total newbie to it.