Re: [commit: ghc] master: Fix dependency generation when GhcLibWays = dyn p (11aa737)

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,[email protected])
> >>>  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" >> [email protected]
> >>
> >>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