Installation issue feedback

Describe the bug

Two main points:

https://www.cogentcore.org/core/setup/install

The <code> </code> blocks are not directly highlight-able (with brave browser on amd64 linux) which makes it basically impossible to copy only the installation command itself for cogentcore.

The only easy way to do it to highlight the whole line and do ctrl + C ; paste into an editor, and then copy the command to the terminal. Or manually type the whole thing.

it would be preferable if the installation command (or generally code blocks) had the behavior of single click copy

Additionally, the setup documentation assumes that you have GOPATH set correctly and that your GOBIN was already added to your PATH ; but this should be made explicit and not just assumed as it might confuse people.

core setup may be easy enough to remember or run, but it actually did not work for me on archlinux with my specific hardware, to install all the correct dependencies (#1223).

I recommend that the cogentcore/core runtime dependencies (installed by core setup) be listed somewhere in the installation documentation - even if this information is not useful to most people.

If cogentcore was packaged and installed as a package by the package manager on linux, installing it's runtime dependencies should be handled by the package manager. And it's deps should be installed as dependencies of cogentcore and not explicitly.

However, I assume the exact dependencies vary based on the hardware & os ; and core setup is supposed to detect this. That might be challenging to handle by the package manager automatically. It might work best with different flavors (so to speak) of the package which are intended for specific hardware and which include the specific runtime deps used by cogentcore for that hardware.

Still, i suggest informing the user of the dependencies for different hardware and operating systems, even if this is on a different page of documentation from the setup installation page.

How to reproduce

1) attempt to copy the installation command from here https://www.cogentcore.org/core/setup/install

2) N/A

Example code

No response

Relevant output

No response

Platform

Web

Thank you for the feedback. We are aware of both of those issues and are working on fixing them. The first issue will be resolved by #1051, and we may restructure the install documentation in the meantime such that it is easier to copy. For the second point, I am currently working on #1292 to fix that after receiving similar feedback in #1275 and #1260. I will also add documentation regarding Vulkan on other distros such as Arch Linux as part of that.

Is it possible to statically compile core itself? If I'm not mistaken it uses CGO, so it should actually make it more distribute-able if i'm not mistaken.

Is it possible to create statically compiled (with musl) apps built with core? Non web-apps of course.

Are you asking about using Cogent Core as a static library / building static libraries with core? That might be theoretically possible, but I'm not sure that it would make sense relative to direct linking using Go. We are planning to improve cross-compiling support soon, but if there is any other reason using Cogent Core as a static library would be helpful, I can consider it.

Are you asking about using Cogent Core as a static library / building static libraries with core? That might be theoretically possible, but I'm not sure that it would make sense relative to direct linking using Go. We are planning to improve cross-compiling support soon, but if there is any other reason using Cogent Core as a static library would be helpful, I can consider it.

I'm talking about compiling core on one machine, and using it on a different machine.

If, for instance, core is compiled on arch linux, the gcc runtime dependency is likely to be an incompatible version when run on debian-based distros.

However, after becoming more familiar with the runtime dependency situation, it's clear that gcc runtime dep is not the only issue with doing this, because there are additional runtime dependencies for core which differ based on hardware.

I'm not sure how this is handled internally. However, as a thought experiment, suppose that core was statically compiled with musl, on one linux machine, and then the compiled binary was moved to a different machine. And suppose the first machine had an amd gpu and the second machine had NVIDIA or otherwise different hardware, or even just a built in graphics processor.

Would the (static) compilation of the core binary on the one machine work when the binary is copied to the other machine - assuming the appropriate additional deps were installed, or is the compilation (of core itself) basically specific to the (graphics) hardware of the machine on which it was compiled?

If it would work, then I think it should be possible to have a binary release of this software ; and even if you didn't want to have a binary release of core (because of the rapid pace of development or to avoid supplying an outdated binary which might cause users to report issues that have already been solved) it would still be possible to have it packaged for different distros.

I say possible but it would likely still present a challenge in terms of the runtime deps differing based on the hardware. I'm very familiar with linux packaging, and there are two possible methods for handling this, using either:

optional dependencies
hardware-specific packages

...

For instance on archlinux - it's possible to statically compile a golang program with musl if you install the musl and kernel-headers-musl packages and then use CC=musl-gcc or export CC=musl-gcc with the go build (or go install) command.

This is typically done either as a consideration for making a binary executable more distributable or because of security concerns about the potential for arbitrary code execution ; i.e. if the host system where the binary runs might have compromised libraries.

...

In terms of statically compiling applications with core basically core build would need to observe the CC env.

And sortof on that note, how might it be possible (or is it possible) to set Ldflags when doing core build ? For setting variables at compile time or to set -s -w ldflags ; things like that

Please correct me if I am misunderstanding which core you are referring to in different contexts. The core command line tool ("core tool") itself does not use CGO and thus can be cross-compiled for any platform in the standard Go way using GOOS and GOARCH. The dependencies that core setup installs are necessary for building Cogent Core apps for native platforms, but they are not in any way attached to the core tool binary itself. Apps built with Cogent Core rely on CGO (except on web), but the core tool itself is mainly just a wrapper around other command-line tools (which is why go build also works fine for building apps on desktop; the core tool does a lot more for mobile and web platforms, so you need it there, but there are still no CGO dependencies).

I believe that the dependencies that core setup installs are largely compile-time dependencies, although some of the Vulkan drivers may be needed at runtime (for actual Cogent Core apps, not for the core tool itself).

I do not have much knowledge of the specifics of dependencies in Linux packaging, but it seems like it might be possible to have a package that contains binary versions of the core tool for each architecture (cross-compiled using the Go tool) and a list of platform-specific dependencies to be installed by the package manager for each distro and hardware combination.

I am currently in the middle of a major restructuring of the documentation (#1321), in which I am updating the installation documentation based on your feedback. As such, there will be an easily accessible list of the requisite dependencies for building Cogent Core apps, which could be used for making a Linux package. I am not necessarily interested in doing so right now given ongoing development as you mentioned, but the core tool should be relatively stable within a few months, so it is definitely a future possibility.

For cross-compiling actual Cogent Core apps, we are planning to implement that at some point relatively soon (#1107), likely once we have finished some other major features.

The core tool currently sets the linker flags automatically (it does -s -w by default), but we can certainly add an option to add additional custom linker flags (update: I filed and fixed #1345, so you can do this now with -ldflags).

I will add all of that information to the documentation as well. Please let me know if you have any further questions.

cogentcore / core