On Wed, Oct 11, 2023 at 11:31 PM Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
> > 'Axel Wagner' via golang-nuts writes:
> >
> > > [...]
> > >
> > > What would this do?
> > >
> > > func F(s []any) {
> > > s[0] = "Foo"
> > > }
> > > func main() {
>
Thanks Tim, but my goal is to make things transparent and easy to the users
of my libraries. So I don't want to force them to run Makefiles (in my case
large Bazel builds for one project, Makefile for the other), install
C++/Rust build tools, deal with dockers, etc. Ideally, `go get` would just
Hallöchen!
Kurtis Rader writes:
> On Wed, Oct 11, 2023 at 10:31 PM Torsten Bronger <
> bron...@physik.rwth-aachen.de> wrote:
>
> 'Axel Wagner' via golang-nuts writes:
>
> > [...]
> >
> > What would this do?
> >
> > func F(s []any) {
> > s[0] = "Foo"
> > }
>
Thanks Richard. Indeed, as you pointed out the downside is the bloating of
the git repo, but it makes sense.
But does the user have to manually clone the repository and move the `.a`
file to, let's say, /usr/local/lib, or does a simple `go get` magically
does everything ?
On Thursday, October
On Wed, Oct 11, 2023 at 10:31 PM Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
> 'Axel Wagner' via golang-nuts writes:
>
> > [...]
> >
> > What would this do?
> >
> > func F(s []any) {
> > s[0] = "Foo"
> > }
> > func main() {
> > s := []int{1,2,3,4}
> > F(s)
> > fmt.Print
Hallöchen!
'Axel Wagner' via golang-nuts writes:
> [...]
>
> What would this do?
>
> func F(s []any) {
> s[0] = "Foo"
> }
> func main() {
> s := []int{1,2,3,4}
> F(s)
> fmt.Println(s)
> }
I think most intuitive would be if this behaved as an implicit
instantiation of the function
I would put down Makefile includes for the supported targets and build each
target at a time, as cross compiled shared libraries. This is easier for
linux, harder for windows.
But, you can build/export from docker containers as part of the overall
build process to allow simulated build environment
It isn't a great solution, but I currently include the built library files
and necessary headers in the git repo alongside the Go code. You can see an
example here
https://github.com/richardwilkes/unison/tree/main/internal/skia where I
include the skia library I built for use in my UI framework
On Wed, Oct 11, 2023 at 8:11 PM Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
> Then, all boils down to the fact that you can’t pass []float64 as an
> []any. To be honest, I still don’t fully understand why this is
> forbidden
What would this do?
func F(s []any) {
s[0] = "Foo"
}
On Oct 11, 2023, at 11:09 AM, Torsten Bronger
wrote:
>
> Then, all boils down to the fact that you can’t pass []float64 as an
> []any. To be honest, I still don’t fully understand why this is
> forbidden, so I just accept that the language does not allow it.
I think in the first case []any is
On Wed, Oct 11, 2023 at 8:11 PM Torsten Bronger
wrote:
> Then, all boils down to the fact that you can’t pass []float64 as an
> []any. To be honest, I still don’t fully understand why this is
> forbidden, so I just accept that the language does not allow it.
It's the same reason why one cannot
Hallöchen!
'Axel Wagner' via golang-nuts writes:
> [...]
>
> The two signatures really mean completely different things. Writing
> `func do[S []E, E any]` really means "S has type []E, where E can be
> any type", which is a very different thing from saying "it's a slice
> of the specific type any
Yep, I want a solution on how to distribute C-dependencies of libraries
that use CGO, so end users don't have to manually sort out dependencies of
various libraries.
Thanks for trying though.
On Wednesday, October 11, 2023 at 1:10:12 PM UTC+2 Peter Galbavy wrote:
> Hang on - I missed your orig
Hang on - I missed your original statement that you are building
*libraries* yourself. I am building executables. Sorry for the confusion
and my too-fast scan reading!
On Wednesday, 11 October 2023 at 12:08:53 UTC+1 Peter Galbavy wrote:
> If you link statically, e.g. from my Dockerfile:
>
> g
If you link statically, e.g. from my Dockerfile:
go build -tags netgo,osusergo --ldflags '-s -w -linkmode external
-extldflags=-static'
then the libraries are in the single binary. I also then use "upx" to
compress the resulting binaries to save a little space. The build tags are
there to no
Edit: ...so folks using your library don't need to install them manually ?
What about uninstalling ?
On Wednesday, October 11, 2023 at 12:41:40 PM UTC+2 Jan wrote:
> Thanks Peter, but I don't follow ... I also use docker to build the
> pre-built binaries.
>
> But how do you distribute them, so f
Thanks Peter, but I don't follow ... I also use docker to build the
pre-built binaries.
But how do you distribute them, so folks using your library don't think to
install them ?
On Wednesday, October 11, 2023 at 12:32:57 PM UTC+2 Peter Galbavy wrote:
> I use a docker container (golang:bullseye
I use a docker container (golang:bullseye seems the most compatible) and
build static binaries. This is feasible as long as your dependencies do not
require dynamic loading of dependencies.
Poor (my Dockerfile skills) example
here: https://github.com/ITRS-Group/cordial/blob/main/Dockerfile
Pet
hi,
I'm developing a couple of ML framework/libraries for Go that depend on
C/C++ code. Once C-libraries dependencies are installed, the CGO
integration work great.
Now, for end-users that just want to use these Go libraries, having to
figure out how to manually build and install those C/C++/R
19 matches
Mail list logo
