On Sat, Aug 31, 2013 at 09:36:38AM +0200, Guido Trotter wrote: > On Fri, Aug 30, 2013 at 5:37 PM, Iustin Pop <[email protected]> wrote: > > On Fri, Aug 30, 2013 at 10:28:25AM +0200, Jose A. Lopes wrote: > >> Hi, > >> > >> I took another look at the Makefile regarding this problem and I think > >> there are 3 use cases to focus on. These uses cases concern partial > >> compilation of Haskell sources, i.e., I have compiled some Haskell > >> sources with some flags and other Haskell sources with other flags, > >> and I don't want to mix different flags in the same linkage stage. > >> > >> The three uses cases are: > >> 1. Normal compilation > >> 2. Compilation with profiling > >> 3. Compilation with coverage > >> > >> This means, for example, that we shouldn't mix Haskell object files > >> compiled with profiling with those compiled with coverage. > >> > >> There are other flags that control Haskell compilation, such as, PCRE > >> and Parallel3, that control whether these libraries are available. > >> However, these seem less important in the following sense: they are > >> defined at configure time and they should remain the same while > >> compiling the Haskell binaries. In other words, I don't thinkg that > >> we should worry about someone compiling some Haskell source files with > >> PCRE and some other Haskell source files without PCRE. The same for > >> Parallel3. > > > > Indeed. > > > >> Anyone care to comment ? > > > > I have only one question, in general: what is the goal you're trying to > > achieve? > > > > If it is to eliminate duplicate compilation of the same source file, I > > have two notes to make (and I won't comment more on this thread): > > > > - even if files are compiled twice or N times, you have many CPUs, so > > you're not blocked on it; what's the problem with having 3 CPUs all > > compiling the same file? > > On many machines where we compile ganeti (including: external buildbot > instances, developers' laptops, other virtual machines) there are not > "that many" cpus, or not that many to dedicate to totally parallel > compilation. Reducing the compile time I think is worthwhile (if we > don't break functionality) and is going to make people life better.
Ack. I see your point, in my experience though the effort to make this work correctly could be too high for the gain. > > - the proper way to eliminate duplicate compilation, if you really want > > it, is to simulate/duplicate what Cabal does: build once all files in > > a local package, then link the binaries against the (single, common) > > library; this way, all issues will go away > > > > Doing more Makefile-style work seems to me more worth than trouble. > > > > Ok. But wouldn't that allow the "library" to be compiled with only one > flag (eg. with or without profiling, coverage, and with one single > value for any ifdefs?). If so how is this an improvement over > compiling everything just once (without the suffixes for each > binary?). > (Maybe I'm missing something, here) It's the same, but it would avoid problems. If you use 'plain GHC' (I mean via --make and without a library), you always run into the risk of it trying to recompile a module as it wishes, which could lead to inconsistent binary files between modules. And I say this as I did see it trying to recompile just because module A used different imports from module C than module B did, so it's not only in case of actually updated files. Maybe newer versions are better here? If however you'd compile 'the ganeti internal library' once, and then reuse that via a local package (not sure how exactly this would work without cabal, but…), then GHC would just reuse the package as it is, so you'd know that when compiling a binary just that small/trivial main file could be recompiled. A third way would be to not use --make and track dependencies manually, but that's even worse (IMHO), as it goes too much into GHC internal management. iustin
