On Tue, Oct 30, 2012 at 01:19:31PM +0000, Simon Marlow wrote: > On 30/10/2012 12:29, Ian Lynagh wrote: > >On Tue, Oct 30, 2012 at 12:15:16PM +0000, Simon Marlow wrote: > >>On 30/10/2012 02:48, Ian Lynagh wrote: > >> > >>>+# Setting hisuf/osuf is a kludge. If DYNAMIC_BY_DEFAULT is on, dyn is > >>>+# the first way, and p is another way, then without this kludge we run > >>>+# ghc -M -hisuf dyn_hi -osuf dyn_o -dep-suffix dyn -dep-suffix p > >>>+# which means we get dependencies for .dyn_hi/.dyn_o and > >>>.p_dyn_hi/.p_dyn_o > >>>+# rather than .dyn_hi/.dyn_o and .p_hi/.p_o. > >>>+# With the kludge we also get .hi/.o dependencies that we don't need, but > >>>+# they don't do any harm. > >>>+# We also specify -static, as otherwise we end up with some dependencies > >>>+# on .dyn_dyn_hi files > >>>+$1_$2_MKDEPENDHS_FLAGS += -static -hisuf hi -osuf o > >>> > >>> ifneq "$$(NO_GENERATED_MAKEFILE_RULES)" "YES" > >>> > >>>@@ -34,8 +44,9 @@ $$($1_$2_depfile_haskell) : $$(includes_H_CONFIG) > >>>$$(includes_H_PLATFORM) > >>> $$($1_$2_depfile_haskell) : $$($1_$2_HS_SRCS) $$($1_$2_HS_BOOT_SRCS) > >>> $$($1_$2_HC_MK_DEPEND_DEP) | $$$$(dir $$$$@)/. > >>> $$(call removeFiles,$$@.tmp) > >>> ifneq "$$($1_$2_HS_SRCS)" "" > >>>- "$$($1_$2_HC_MK_DEPEND)" -M $$($1_$2_MKDEPENDHS_FLAGS) \ > >>>+ "$$($1_$2_HC_MK_DEPEND)" -M \ > >>> $$(filter-out -split-objs, $$($1_$2_$$(firstword > >>> $$($1_$2_WAYS))_ALL_HC_OPTS)) \ > >>>+ $$($1_$2_MKDEPENDHS_FLAGS) \ > >>> $$($1_$2_HS_SRCS) > >>> endif > >>> echo "$1_$2_depfile_haskell_EXISTS = YES" >> $$@.tmp > >> > >>I encountered this yesterday. I wonder whether we could just use > >>$$($1_$2_v_ALL_HC_OPTS) instead of $$($1_$2_$$(firstword > >>$$($1_$2_WAYS))_ALL_HC_OPTS), and then we wouldn't need the kludge > >>(though we'd still need a comment to explain why). Wouldn't that be > >>better? > > > >$1_$2_v_ALL_HC_OPTS is only defined if the v way is in GhcLibWays. > > Hmm, well, I think it might make sense to ensure it was always > defined and then use it. Here we really do want the "v" way rather > than just picking the first way from the list and then hacking > around the problems.
I think the Right Thing would be to run "ghc -M" for each way separately. I assume you want to avoid that because it would take a while if building several ways? Although is that really important, when development builds generally only build 1 way? If we want to stick with the current approach, then wouldn't it make more sense for "ghc -M" to ignore any way flags and osuf/hisuf, and for e.g. "ghc -M -dep-suffix '' -dep-suffix p_ ..." to generate rules for ".o/.hi" and ".p_o/.p_hi"? Thanks Ian _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc