Faster change-compile-test cycle

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Faster change-compile-test cycle

Marcel Wiesweg
Hi,

with the inclusion of digikamimageplugins, recompilation is now even slower
because a change in any source file in libdigikam (=most files) will lead to
relinking every single image plugin. And linking is slow these days.

I added this to the top Makefile.am (tabs at the beginning, not spaces):

fastcompile:
        for i in libs utilities digikam kioslave; \
        do \
                cd $$i; \
                make || exit 1; \
                cd ..; \
        done

and a "make fastcompile" skips the imageplugins if you work on the core.
I would be interested if a more elegant solution is possible...but please dont
invest more than a few minutes, CMake is coming soon ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: Faster change-compile-test cycle

Gilles Caulier-4


2007/3/25, Marcel Wiesweg <[hidden email]>:
Hi,

with the inclusion of digikamimageplugins, recompilation is now even slower
because a change in any source file in libdigikam (=most files) will lead to
relinking every single image plugin. And linking is slow these days.

I added this to the top Makefile.am (tabs at the beginning, not spaces):

fastcompile:
        for i in libs utilities digikam kioslave; \
        do \
                cd $$i; \
                make || exit 1; \
                cd ..; \
        done

and a "make fastcompile" skips the imageplugins if you work on the core.
I would be interested if a more elegant solution is possible...but please dont
invest more than a few minutes, CMake is coming soon ;-)

no more elegant...

Perhaps we can use the macro "DO_NOT_COMPILE=imageplugins" when we work only on core...

Gilles
 



_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: Faster change-compile-test cycle

Gilles Caulier-4
others way, more simple, used here to work on core only : make a svn checkout of digiKam and remove imageplugins and showfoto folders. perform autotools, and that all. Do not update these folders later. Nota: i remember to have read a svn command to ignore some folders with "svn up", but i cannot remember where i have seen that...

Also, I have 2 others copy of digikam in my computer:

- one to compile all with --enable-debug=full.
- one to compile all with --enable-final.

The last one is very important to check if all will be compiled fine for final package. Sometime, compilation is broken (less now since I have polished all Makefile.am with 0.9.0 release)

Gilles

2007/3/26, Gilles Caulier <[hidden email]>:


2007/3/25, Marcel Wiesweg <[hidden email]>:
Hi,

with the inclusion of digikamimageplugins, recompilation is now even slower
because a change in any source file in libdigikam (=most files) will lead to
relinking every single image plugin. And linking is slow these days.

I added this to the top <a href="http://Makefile.am" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Makefile.am (tabs at the beginning, not spaces):

fastcompile:
        for i in libs utilities digikam kioslave; \
        do \
                cd $$i; \
                make || exit 1; \
                cd ..; \
        done

and a "make fastcompile" skips the imageplugins if you work on the core.
I would be interested if a more elegant solution is possible...but please dont
invest more than a few minutes, CMake is coming soon ;-)

no more elegant...

Perhaps we can use the macro "DO_NOT_COMPILE=imageplugins" when we work only on core...

Gilles
 




_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel