英文:
Conditionally build go sources for x86 and mips
问题
我有一些专门为mips构建的Go源代码。我想让它们在x86上编译，以便在x86上运行一些非特定于架构的代码。我的源代码组织如下：
ipmi.go：# 仅在mips上构建。
package main
import (
"foo"
"bar"
)
/*
#cgo LDFLAGS: -lfreeipmi
#define FOO 1
一些C代码
*/
import C
// Go代码
func gofunc1() {
}
func gofunc2() {
}
// 更多Go代码
hardware.go：# 全部是Go代码
package main
import (
"很多"
"库"
)
func main() {
// 一些Go代码
ret1 = gofunc1()
ret2 = gofunc1()
// 使用ret1和ret2做其他事情。
// 更多Go代码
}
如何在x86上构建这些源代码的最佳方法是什么？
我在ipmi.go中添加了以下内容来限制它的构建架构：
// +build linux,mips,cgo
hardware.go仍然无法编译，因为它调用了gofunc1()和gofunc2()。由于hardware.go始终需要调用gofunc1()和gofunc2()，我无法想到任何有条件地为x86编译这些源代码的方法。任何见解都将很有帮助。
谢谢！
英文:
I have some go sources that are exclusively built for mips. I'm trying to get them to compile on x86 so as to run select, non-architecture-specific code on x86 as well. My sources are organized as below:
ipmi.go: # Only builds on mips.
package main
import (
"foo"
"bar"
)
/*
#cgo LDFLAGS: -lfreeipmi
#define FOO 1
some c code
*/
import C
// go code
func gofunc1() {
}
func gofunc2() {
}
// more go code
hardware.go: # All go code
package main
import (
"lots"
"of"
"libs"
)
func main() {
// some go code
ret1 = gofunc1()
ret2 = gofunc1()
// Use ret1 and ret2 to do something else.
// more go code
}
What's the best way to enable building these sources on x86?
I added the following to ipmi.go to restrict the arch on which it is built:
// +build linux,mips,cgo
hardware.go still fails to compile since it calls gofunc1() and gofunc2(). Since hardware.go will always need to call gofunc1() and gofunc2(), I can't think
of any way to conditionally compile these sources for x86. Any inisghts will be helpful.
Thanks
答案1
得分: 4
> 构建约束
>
> 构建约束
>
> 构建约束，也称为构建标签，是一个以行注释形式开始的内容，用于列出文件应该包含在包中的条件。约束可以出现在任何类型的源文件中（不仅限于Go），但它们必须出现在文件的顶部附近，仅由空行和其他行注释分隔。这些规则意味着在Go文件中，构建约束必须出现在包声明之前。
>
> 为了将构建约束与包文档区分开，一系列构建约束后必须有一个空行。
>
> 仅在使用cgo且仅在Linux和OS X上构建文件：
>
> // +build linux,cgo darwin,cgo
>
> 这样的文件通常与另一个文件配对，该文件实现其他系统的默认功能，在这种情况下，它会带有以下约束：
>
> // +build !linux,!darwin !cgo
按照文档中的建议进行操作。例如，
hardware.go:
package main
import "fmt"
func main() {
fmt.Println(ipmi())
}
ipmi.go:
// +build linux,mips,cgo
package main
func ipmi() string { return "mips" }
ipmi_not.go:
// +build !linux !mips !cgo
package main
func ipmi() string { panic("not implemented") }
英文:
> Package build
>
> Build Constraints
>
> A build constraint, also known as a build tag, is a line comment that
> begins
>
> // +build
>
> that lists the conditions under which a file should be included in the
> package. Constraints may appear in any kind of source file (not just
> Go), but they must appear near the top of the file, preceded only by
> blank lines and other line comments. These rules mean that in Go files
> a build constraint must appear before the package clause.
>
> To distinguish build constraints from package documentation, a series
> of build constraints must be followed by a blank line.
>
> To build a file only when using cgo, and only on Linux and OS X:
>
> // +build linux,cgo darwin,cgo
>
> Such a file is usually paired with another file implementing the
> default functionality for other systems, which in this case would
> carry the constraint:
>
> // +build !linux,!darwin !cgo
Follow the suggestion in the documentation. For example,
hardware.go:
package main
import "fmt"
func main() {
fmt.Println(ipmi())
}
ipmi.go:
// +build linux,mips,cgo
package main
func ipmi() string { return "mips" }
ipmi_not.go:
// +build !linux !mips !cgo
package main
func ipmi() string { panic("not implemented") }
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论