Tcl connector: implement API v1

[DigitalBrains1]

A breaking change was made to the API. I realized the extra indirection
of defining a procedure was not actually needed in order to elegantly
pass in the argument specifying where to create the namespace.

Vivado tests in clash-testsuite now use the Tcl connector, and handle
a top component name that differs from the Haskell function that
specifies that component. Closes: #2264

Still TODO:

• Write a changelog entry (see changelog/README.md)
• Check copyright notices are up to date in edited files

[DigitalBrains1]

You could leave this PR with a partial implementation open until you really need it, and perhaps another PR with the full implementation will make this obsolete before that. It depends on how quickly you'll get to the situation where you need to pass Xilinx.Floating to Vivado.

[DigitalBrains1]

I've just pushed the full Tcl connector implementation instead of the earlier partial one.

[DigitalBrains1]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[martijnbastiaan]

LGTM! I'm not familiar enough with TCL to catch subtle mistakes, but given that the testsuite uses it now I don't see a reason to not merge.

[DigitalBrains1]

Ah, Martijn, I hadn't expected you around. If you're still following this, I'd like to make some comments. I think this is mergeable, but I noted two things:

1. I looked at PR GenTcl restructuring #2319, specifically Clash.LocatedManifest. I intended to include it some way here, but it ran afoul of issue Refactor BuildSpecific to pass in the full qualified name #2264. PR 2319 looked up the manifest with manifestLocationFromStrName hdlDir qualName, but the code here that fixes 2264 is:

   do
   [...]
   manifests <- getManifests (dir </> "*" </> manifestFilename)
   let [(dropFileName -> topEntityDir, _)] =
           filter ((== top) . topComponent . snd) manifests

   I couldn't really see how you would want to use Clash.LocatedManifest here, what modifications to that module would work for your purposes.
2. You noted that Clash.DataFiles.tclConnector returning a path to a Cabal data file might not work under all circumstances with Stack, and I think that is still the case: discussions pointed to Add stack build --prefix option commercialhaskell/stack#848 , which is still open. Generally the suggestion is to use file-embed (which isn't perfect in Stack either: stack ghci can't find file-embed files when the package is in a subdirectory commercialhaskell/stack#1057 ). Should I, already at this stage, re-implement Clash.DataFiles.tclConnector to return a ByteString with the contents rather than a path to the file on the filesystem? Or shall we do this in a later PR?

[vmchale]

Should I, already at this stage, re-implement Clash.DataFiles.tclConnector to return a ByteString with the contents rather than a path to the file on the filesystem? Or shall we do this in a later PR?

I prefer the data-files approach - but in any case I think you don't need to use file-embed to get this specific PR merged in!

[vmchale]

I am approving; the test suite still works on my computer.

(The TCL looks strictly better as far as I can tell)