- Status Closed
- Percent Complete
- Task Type Bug Report
- Category QCAD (main)
-
Assigned To
Andrew - Operating System All
- Severity Low
- Priority Very Low
- Reported Version 3.3.4
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: QCAD Bugtracker
Opened by Tamas TEVESZ - 16.10.2013
Last edited by Andrew - 18.10.2013
Opened by Tamas TEVESZ - 16.10.2013
Last edited by Andrew - 18.10.2013
FS#944 - Build system: some dependencies are not rebuilt when needed
As came up towards the end of FS#892 .
What happens is a change in src/3rdparty/dxflib/src/dl_dxf.cpp does trigger a rebuild of release/libdxflib.a, but this does not, in turn, trigger a re-link of plugins/libqcaddxf.so, a (the?) consumer of libdxflib.a.
This causes partial rebuilds to be broken (I think I got puzzled by this earlier too).
How to reproduce: on a fully built tree, `touch src/3rdparty/dxflib/src/dl_dxf.cpp’ then `make’. Nothing but libdxflib.a gets rebuilt.
Hm, now that I think about it, this (perhaps hidden in other places too) could be the cause of my repeated attempts to make parallel builds (as in `make -j2' and up). It always takes several passes, stopping with weird problems, but it eventually succeeds after several tries.
Did you ever try and succeed in parallel builds?
Is this on FreeBSD or another platform?
The DXF plugin (libqcaddxf.so) is relinked if post target dependencies have changed. Post target dependencies are defined in 'qcad/src/io/dxf/dxf.pro':
I guess that none of these conditions apply for FreeBSD. Perhaps unix { ... } rather than linux { ... } would cover FreeBSD as well. Could you check this? You can produce debugging information with qmake using the message function in a .pro file:
Yes, I'm usually building with make -j6 on Mac OS X and Linux (quad core CPU with hyperthreading enabled).
Hm. Good catch on the FreeBSD bit, and I think therein lies the problem: I don't think there's a linux scope. There is win32, macx and unix; linux, by itself, won't match (that would be "linux*", for the arch-comp matching, as per mkspecs).
If I do this (just a quickie):
then libqcaddxf.so does get rebuilt, even on Linux. In its current form (ie. as shown above in your comment), libqcaddxf.so does not get rebuilt, even on Linux.
Actually... in shared.pri, there already seem to be traces of abstracting this difference:
So for the static link case (dxflib and stemmer), it can be written simply as
The abstraction is already done in shared.pri.
For the dynamic lib case, variables similar to RLIBPRE and RLIBPOST can be added, then this all gets concentrated in one place, and spatialindex can too be just one POST_TARGETDEPS clause in src/spatialindex/spatialindex.pro.
Thanks for the suggestion, that makes sense indeed.
This should be implemented in:
https://github.com/qcad/qcad/commit/2f84c4a96120e35940cdae6faadc70eda5ee38a6