Support asm/cmm/js sources in executable components (#8639)

[JoshMeredith]

Implementation for #8639

The code for building each of c/cpp/asm/cmm/js is factorised into a local function buildExtraSources. The local function is separate per library/executable building - i.e. no factorisation between these two stages is attempted.

Added tests:

• cabal-testsuite/PackageTests/CmmSourcesExe: based on the sibling CmmSources test, with the source directories and .cmm
  file moved into the executable, and the library removed
• cabal-testsuite/PackageTests/JS/JsSourcesExe: as above for the .js source.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Include manual QA notes if your PR relates to cabal-install.

Bonus points for added automated tests!

[hsyl20]

LGTM

[hsyl20]

Could someone review this PR, please? It would be nice to get it backported to 3.10 to avoid this surprising bug for users trying to use the JS backend in 9.8. Thanks!

[Kleidukos]

@Mergifyio backport 3.10

[mergify]

backport 3.10

✅ Backports have been created

• #9130 Support asm/cmm/js sources in executable components (#8639) (backport #9061) has been created for branch 3.10 but encountered conflicts

[hsyl20]

Thanks @Kleidukos !

[ulysses4ever]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[ulysses4ever]

Fourmolu is failing for an unrelated reason. A fix is in flight.

[Mikolaj]

@Kleidukos, @hsyl20, @JoshMeredith: It turns out nobody resolved the conflicts in the backport #9130 and so this is not slated for release in cabal 3.10.2.0, but only in cabal 3.12.1.0 (which we optimistically expect to get released just after 3.10.2.0). Is that a problem? Is there a volunteer for an emergency conflict resolution to squeeze this in into 3.10 one minute before midnight?

[hsyl20]

It shouldn't be a problem, we'll just recommend 3.12 for the JS backend.

[alt-romes]

@JoshMeredith

In this change, why does dynLinkerOpts not have jsObjs? I suppose we cannot dynamically link jsObjects?

@@ -1794,14 +1676,14 @@ gbuild verbosity numJobs pkg_descr lbi bm clbi = do
                 PD.extraFrameworkDirs bnfo
           , ghcOptInputFiles =
               toNubListR
-                [tmpDir </> x | x <- cLikeObjs ++ cxxObjs]
+                [tmpDir </> x | x <- cLikeObjs ++ cxxObjs ++ jsObjs ++ cmmObjs ++ asmObjs]
           }
       dynLinkerOpts =
         mempty
           { ghcOptRPaths = rpaths
           , ghcOptInputFiles =
               toNubListR
-                [tmpDir </> x | x <- cLikeObjs ++ cxxObjs]
+                [tmpDir </> x | x <- cLikeObjs ++ cxxObjs ++ cmmObjs ++ asmObjs]
           }
       replOpts =
         baseOpts

[Mikolaj]

@JoshMeredith: a humble ping?

@hsyl20: do you perhaps know the answer off the top of you head?

[JoshMeredith]

Hi, sorry I saw this and forgot to send the reply.

Yes, it's intentional that we don't currently dynamically link JavaScript. Our team hasn't discussed if it's possible, maybe @hsyl20 or @luite have ideas.