Ian Lance Taylor <i...@golang.org> schreef op 20 december 2018 19:20:13 CET: > On Thu, Dec 20, 2018 at 8:02 AM Peter Kleiweg <pklei...@xs4all.nl> > wrote: > > > > Ian Lance Taylor <i...@golang.org> schreef op 20 december 2018 > 16:47:20 CET: > > > On Thu, Dec 20, 2018 at 1:07 AM Peter Kleiweg <pklei...@xs4all.nl> > > > wrote: > > > > > > > > Ian Lance Taylor <i...@golang.org> schreef op 20 december 2018 > > > 00:06:58 CET: > > > > > > > > > How about this: > > > > > > > > > > Move the C files to a subdirectory. Write a script or > Makefile > > > that > > > > > compiles the C files into a .syso file in the main package > > > directory, > > > > > using flags that you specify. Fetch the package using `go get > > > -d`. > > > > > Run the script with the appropriate flags to generate the > .syso > > > file. > > > > > At that point `go build` should work. > > > > > > > > The C files are part of the package. This would mean, > downloading > > > the package and reorganize it. > > > > > > I was imagining that this rearrangement would be done at the > package > > > source, not each time it was downloaded. > > > > That would be nice, but the package developers are not on our > payroll. They do not cater for our odd requirements. > > > > > > I was thinking there might be a better way. Add a file with > local > > > configuration, a file that imports '"C" and sets CFLAGS and > LDFLAGS, > > > without modifying the official package files. This works, except > for > > > packages that rely on pkg-config. I don't see how I can modify the > > > contents of PKG_CONFIG_PATH in a Go file. > > > > > > Sure, that could work too. > > > > > > I don't understand why pkg-config would need to be correct on a > > > specific system. Why would pkg-config be incorrect? > > > > Sometimes, standard systems are too rigid. Things clash. Sometimes, > you have to bend the accepted practices to get very odd bunches of > software to work together. So you work in an odd environment. The Gnu > build system handles this very well. It gives you options to tweak > anything. In comparison, Go is rigid, and becoming more rigid. It > assumes too much sameness on development platforms. > > > > Why would pkg-config be incorrect? Who cares. I just want to be able > to fix it, when I need to. And I need to. > > Adding the file with the local configuration should work just as well > when you need to adjust pkg-config results as it would for a package > that does not use pkg-config.
No it doesn't. Unless I modify the original code, there is no way to switch off a failing call to pkg-config. I don't think modifying third-party package files is good idea. > I'm sorry you have trouble with the go tool. But to me it sounds like > you were using binary packages as a hack to get around that trouble, > not as a clean solution. There are good reasons why binary packages > do not work in general, as I outlined earlier. I don't want to use binary packages. But at the moment, it's the only working solution that doesn't require modifying third-party package files. > It sounds like you should be using a more flexible tool, such as make, > rather than trying to force-fit your complex and unusual scenario into > the go tool. I don't need make. A simple script will do. Or rather, it should. I can install the packages, but I can't import them because Go is too limited to remember the necessary environment settings. Starting from Go 1.14 I can only fix it by modifying files that should not be modified. Y -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
