Make dependencies in KStars

[Akarsh Simha]

ccache is a great solution. The problem we have is that some header files
like kstars.h and skymap.h are included everywhere in the code. So one tiny
change to either of these files and the entire project (almost) gets
recompiled. The solution is to break these classes and make things modular
so we don’t have to route everything through the SkyMap or KStars classes,
but as you can imagine this would be a major undertaking.

Regards
Akarsh


On Wed, May 13, 2020 at 02:51 Jasem Mutlaq <mutlaqja at ikarustech.com> wrote:

> Try to install ccache and enable it in CMake, it helps reduce
> compilation times.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Wed, May 13, 2020 at 5:56 AM Hy Murveit <murveit at gmail.com> wrote:
>
>> *TL;DR* KStars makefiles seem to recompile everything (or a lot anyway)
>> when seemingly small 'git pulls' come in. Wondering if there's something
>> wrong with the setup. I'm not a cmake wizard.
>>
>> *Background:* I compile/test KStars mostly on my MacbookPro, and I find
>> the compile times very reasonable there. However, when I am ready to test
>> something with a telescope, I compile and run on my 4Gb RPi4. There it
>> takes about 40 minutes for me to completely build the system (I run 'make
>> -j6 kstars' and am compiling RelWithDebInfo) and for some reason, it often
>> seems to build most of the system.
>>
>> *Gripe: *When I change a single .cpp in an Ekos module, yes, it seems to
>> work fine, just recompile that file, then build the library, then build the
>> binary. However, often I seem relatively small updates come in, and I
>> notice very long compiles.  Do others notice this? I wish I could give
>> concrete examples. Does anyone know how to analyze? E.g. is there a command
>> to see what would be compiled (and why) before running the make? Is there a
>> way to improve this?
>>
>> Thanks,
>> Hy
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20200513/74d232b7/attachment.htm>