Tk dependencies should be optional

[b-lang-org]

Tk dependencies should be optional

[thotypous]

It's currently (6a8cedf) possible to build without Tk by passing TCLEXES=bluetcl BLUEWISH_TOOLS= to make.

[quark17]

The only tool that really needs libX11 etc is bluewish, and I think it's entirely reasonable to have a compile option that avoids building that and therefore avoids the need for X11 etc. I believe, though, that currently bluetcl unnecessarily has the same requirements as bluewish, probably because they share the same compile flags (perhaps in an effort to avoid recompilation of the Haskell modules when the the flags change).

[bpfoley]

Yeah, this makes sense to me. If you want to use bluesim, tcl is currently required, but Tk should be a (build time) option.

I suspect the best way to do this would be to split the entire bluespec codebase up into several Haskell modules that can be compiled independently, and only have tk deps for bluewish, and tcl deps for bluetcl.

[thotypous]

As a related question, are there plans for releasing the workstation (BDW) as open source? I was curious as to whether bluewish is used outside of BDW. Do you have any customers who wrote in-house tools using Tk?

[quark17]

I've created a version of the Makefile that removes the Tcl/Tk/X11 dependencies from BSC and the TK/X11 dependencies from Bluetcl. It's attached to PR #144 and just waiting for @bpfoley to review.

I don't know if anyone is using Bluewish aside from the Workstation GUI. But hopefully that's moot with the above Makefile fix.

We do plan to release the GUI as open source, but I'm not sure when. Issue #69 is open for that.

[quark17]

PR #144 has been merged, so now only the bluewish binary should require tk or X11 to run. The user of a release now won't need tk/X11 for anything else in the release. However, the builder of the release will still need tk/X11 to build bluewish. The Makefile also requires wish and xvfb-run just to construct variables (even if it doesn't build the bluewish target), but these are for itk and that might go away when issue #149 is resolved.

@thoughtpolice, I assume that you would still want a way to build without tk/X11/etc available? For that, I think it would be reasonable to add a variable which disables the building of bluewish (and the construction of any itk variables, if they exist) when provided. For example, make NO_TK=1 or NOWISH or NOX11 or something. Does that work? Any naming preferences?

Another option would be to create a variable for specifying a type of build. For example, maybe BSC_BUILD_TYPE could be assigned all to turn on build/install of the developer tools (which are not currently built by default), or it could be set to no_wish or other values to specify different subsets of tools to build. Or we could even allow defining BSC_BUILD_TARGETS with the explicit list of targets.

I'm fine with NO_TK=1 but I'm flexible.

[quark17]

Maybe we don't even need to produce a bluewish executable, now that we're not statically linking tcl/tk/itcl/itk. The only difference in bluewish is that it is pre-linked with the tk library (and may possibly have pre-loaded the Tk package?), but bluetcl can dynamically load that from the user's system:

$ bluetcl
% package require Tk
8.5.9
% package ifneeded Tk 8.5.9
load /System/Library/Frameworks/Tk.framework/Resources/Scripts/../../Tk Tk

[thotypous]

bluetcl can dynamically load that from the user's system

Very well noticed! One build dependency less and one 26MB binary less installed in the system 😊

[bpfoley]

Maybe we don't even need to produce a bluewish executable, now that we're not statically linking tcl/tk/itcl/itk. The only difference in bluewish is that it is pre-linked with the tk library

Yes! Especially since bluewish.hs is literally a copy of bluetcl.hs. Let's just remove that target and binary entirely! As you pointed out to me, it'll also allow us to remove the build rules removed in #158