QCAD

QCAD - 2D CAD System.

Click here for a documentation of the DokuWiki formatting syntax that can be used in reports

Please search for existing tasks (also closed ones) before opening a new task.

Please make sure that you are using the latest Version of QCAD before posting a bug (menu Help - Check for Updates)

Tasklist

FS#944 - Build system: some dependencies are not rebuilt when needed

Attached to Project: QCAD
Opened by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 20:39 GMT+2
Last edited by Andrew (andrew) - Friday, 18 October 2013, 13:24 GMT+2
Task Type Bug Report
Category Main
Status Closed
Assigned To Andrew (andrew)
Operating System All
Severity Low
Priority Normal
Reported Version 3.3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.

This task depends upon

Closed by  Andrew (andrew)
Friday, 18 October 2013, 13:24 GMT+2
Reason for closing:  Fixed
Comment by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 21:00 GMT+2

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?

Comment by Andrew (andrew) - Wednesday, 16 October 2013, 21:08 GMT+2
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

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':

win32 {
    POST_TARGETDEPS += ../../../$$ROUTDIR/dxflib.lib
}
macx {
    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
}
linux {
    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
}

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:

message("Some message")
Comment by Andrew (andrew) - Wednesday, 16 October 2013, 21:10 GMT+2
Did you ever try and succeed in parallel builds?

Yes, I'm usually building with make -j6 on Mac OS X and Linux (quad core CPU with hyperthreading enabled).

Comment by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 21:29 GMT+2

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):

diff --git a/src/io/dxf/dxf.pro b/src/io/dxf/dxf.pro
index d9f85a1..ca207f5 100644
--- a/src/io/dxf/dxf.pro
+++ b/src/io/dxf/dxf.pro
@@ -21,10 +21,10 @@ LIBS += -lqcadcore -lqcadentity -ldxflib -lqcadoperations
 
 win32 {
     POST_TARGETDEPS += ../../../$$ROUTDIR/dxflib.lib
-}
-macx {
-    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
-}
-linux {
-    POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+} else {
+    macx {
+        POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+    } else {
+        POST_TARGETDEPS += ../../../$$ROUTDIR/libdxflib.a
+    }
 }

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.

Comment by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 22:14 GMT+2

Actually... in shared.pri, there already seem to be traces of abstracting this difference:

win32 {
    RLIBPRE =
    RLIBPOST = .lib
}
else {
    RLIBPRE = lib
    RLIBPOST = .a
}

So for the static link case (dxflib and stemmer), it can be written simply as

POST_TARGETDEPS += ../../$$ROUTDIR/$${RLIBPRE}dxflib.$${RLIBPOST}

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.

Comment by Andrew (andrew) - Friday, 18 October 2013, 13:24 GMT+2

Thanks for the suggestion, that makes sense indeed.
This should be implemented in:
https://github.com/qcad/qcad/commit/2f84c4a96120e35940cdae6faadc70eda5ee38a6

Loading...