I've also noticed that make -k isn't working in the cmake builds. Whenever
it finds an error, it halts the compilation completely, instead of
ignoring (like I told it to). What's even more interesting, going to
another directory, completely unrelated to the error, also doesn't work.
Also, it's
On Wed, Mar 29, 2006 at 07:38:07PM +0200, Thiago Macieira wrote:
> I've also noticed that make -k isn't working in the cmake builds. Whenever
> it finds an error, it halts the compilation completely, instead of
> ignoring (like I told it to). What's even more interesting, going to
> another dire
Matt Rogers wrote:
> On Wed, Mar 29, 2006 at 07:38:07PM +0200, Thiago Macieira wrote:
>
>>I've also noticed that make -k isn't working in the cmake builds. Whenever
>>it finds an error, it halts the compilation completely, instead of
>>ignoring (like I told it to). What's even more interesting,
Brad King wrote:
>When a compilation error prevents some library A from building then any
>library B that depends on (links to) library A will not attempt to
>build. Technically library B's object files could be built but library
>B could still not be linked under "make -k".
This is exactly what
On Wednesday 29 March 2006 21:01, Thiago Macieira wrote:
> Brad King wrote:
> >When a compilation error prevents some library A from building then any
> >library B that depends on (links to) library A will not attempt to
> >build. Technically library B's object files could be built but library
> >
Alexander Neundorf wrote:
>So if I understood correctly, just use make -i ?
>
>cmake generates makefiles which do more dependency checking than we had
> with autotools AFAICT, and that's actually a good thing.
This is not a showstopper, but the dependencies generated in the top-level
Makefile are
Am Donnerstag, 30. März 2006 10:02 schrieb Thiago Macieira:
> And as David said, for the future, it would be nice to have a flat
> build -- i.e., not launching a separate make process for each
> subdirectory.
yeah, but that's included already in my dream named "unsermake generator" :)
Greetings,
Thiago Macieira wrote:
> Alexander Neundorf wrote:
>
>>So if I understood correctly, just use make -i ?
>>
>>cmake generates makefiles which do more dependency checking than we had
>>with autotools AFAICT, and that's actually a good thing.
>
>
> This is not a showstopper, but the dependencies ge
Brad King wrote:
>Most make implementations will not re-read dependencies from makefiles
>once building has started (GNU make does in some cases, but other UNIX
>makes, NMake, Borland Make, etc. do not). If a source file in target B
>is generated by the executable target A then B cannot build even
On Thursday 30 March 2006 19:36, Thiago Macieira wrote:
...
> Even without the flat build and starting compilation of the next target's
> sources while the current one hasn't finished linking (which means the
> compile farm starves for a while), cmake building of kdelibs is faster
> than the equiva
Alexander Neundorf wrote:
>> Even without the flat build and starting compilation of the next
>> target's sources while the current one hasn't finished linking (which
>> means the compile farm starves for a while), cmake building of kdelibs
>> is faster than the equivalent unsermake build.
>
>Reall
On Friday 31 March 2006 04:20, Thiago Macieira wrote:
> Alexander Neundorf wrote:
> >> Even without the flat build and starting compilation of the next
> >> target's sources while the current one hasn't finished linking (which
> >> means the compile farm starves for a while), cmake building of kdel
Matt Rogers wrote:
>On Friday 31 March 2006 04:20, Thiago Macieira wrote:
>> Alexander Neundorf wrote:
>> >> Even without the flat build and starting compilation of the next
>> >> target's sources while the current one hasn't finished linking
>> >> (which means the compile farm starves for a while)
13 matches
Mail list logo
