Suggestion: Ease cross compiling, reduce reliance on env vars

[4LT]

I don't know if this would be in-scope for the project or not but...

I found it difficult to cross-compile from Linux to Windows. While possible, I think it could be more ergonomic.

The command I eventually landed on looks like this:

RUSTFLAGS="-L scratch/tcl-${tcl_tag}/win/build"\
    PKG_CONFIG_ALLOW_CROSS=1\
    BINDGEN_EXTRA_CLANG_ARGS='-D__int64="long long" -Dssize_t=int64_t'\
    cargo build --target=x86_64-pc-windows-gnu --release

Where scratch/tcl-${tcl_tag}/win/build is the relative path where I have tcl86.dll built. (Additionally, I have to create a symlink from tcl8.6.dll -> tcl86.dll for the tcl crate to find the lib, based on the default make behavior from the Tcl source.)

Ideally I'd like to be able to configure the path to the Tcl lib elsewhere and be able to just run cargo build --target=x86_64-pc-windows-gnu --release to build an executable.

In particular, the BINDGEN_EXTRA_CLANG_ARGS='-D__int64="long long" -Dssize_t=int64_t' bit is a bit silly, apparently some sort of clang behavior that deviates from GCC. (So far as I can tell, __int64 is only recognized by MSVC, although clang already appears to define __GNUC__ by default, so I have no idea why __int64 is reached).

---

I'd also like to say that you're bindings are working terrifically! I've had no problems with the code I've written to consume the tcl crate, and I've had reports that it's working under Windows (through a cross-compile build I've handed out) as well.

[oooutlk]

I have tested building this library on Debian, FreeBSD and Windows (msvc/gnu), but not cross compiling. Glad to know it works with cross compiling too.

This project depends on clib to provide C API bindings to tcl/tk. I guess clib's build.rs can set PKG_CONFIG_ALLOW_CROSS=1 or add extra args for bindgen under cross compiling environments.

The tcl's Cargo.toml tries the best to guess the name of tcl library file.

[package.metadata.inwelling.clib.spec.tcl86.libs]
tcl = ["libtcl86.so", "libtcl8.6.so", "libtcl.so", "libtcl86.a", "libtcl.a", "libtcl86.dll.a", "libtcl.dll.a", "tcl86t.dll", "tcl86t.lib"]

If your dll's name is "tcl86.dll", I guess putting it in the array may help to eliminate the necessary of symlink.

[oooutlk]

Currently the clib crate assumes that native libraries have already been compiled and installed at well known paths/ containing predictable patterns. It does not support source code downloading and compiling yet. Are you requiring such a feature in clib? Seems valuable.

[4LT]

It does not support source code downloading and compiling yet. Are you requiring such a feature in clib?

I don't require it, but it would be nice to have. For Windows platforms I'm distributing libraries for Tcl/Tk with my application as a matter of simplifying installation. I have a script for downloading and building Tcl and Tk, so I've got all my needs covered, but it was a chore to set up.

I have a build script here to demonstrate the difficulty:

https://github.com/4LT/pectin/blob/master/cross_windows.sh

As an example of the nuances I need to account for, make install actually MUST be run for Tk because pkgIndex.tcl is generated from the Makefile

Anyways, this is just something I wanted to bring to your attention. As I said, it's a "nice to have"; I would appreciate the process being simplified, but I have no expectations.

[smaudet]

I'm having trouble compiling on windows at all - I have everything compiling, right up to the link part (where it spits some nonsense about tk.dll.lib not existing).

I know the package says that it doesn't work well with pkg-config, so if there are windows build instructions, I'm no stranger to difficult builds. :)

[smaudet]

It doesn't work on linux either (manjaro install).

It looks like a nice library but I'm going to say you need to offer more instructions on how to get this running, if neither windows nor linux will work out of the box...

[oooutlk]

I'm having trouble compiling on windows at all - I have everything compiling, right up to the link part (where it spits some nonsense about tk.dll.lib not existing).

I know the package says that it doesn't work well with pkg-config, so if there are windows build instructions, I'm no stranger to difficult builds. :)

I’m not sure if you had read this.

And, this is an issue about cross compiling, not installing failures. I think you’d better starting a delicated issue for your own.

[smaudet]

I think you’d better starting a delicated issue for your own.

Perhaps.

I’m not sure if you had read this.

So I tried, actually, three different tcl/tk installations (ActiveState, which was an absolute pain to get, normal tcl/tk, and I even compiled my own tcl/tk with visual studio). I'm not sure what counts as "installed" and your documentation is sparse on that definition. Per my other comment, you may want to consider removing the "magic" clib and expose more of the binding process, its clearly not working well, and its fairly obtuse to debug.

FWIW, I got the other tcl/tk binding packages working fine (the one's that require you to bind to a separate install), I was hoping for a more embedded approach with this library. But clearly its your library not tk not tcl, that are the issue, as it can't compile itself on either linux or windows or linux to windows...