FAQ
After searching this mailing list and reading the syscall package docs,
I've come the obvious conclusion that gathering the uid, gid, and mode of a
file is not possible outside of the syscall package -- well if I want to
stick to the stdlib.

Here is what I'm trying to do:

https://github.com/kelseyhightower/confd/blob/master/template_resource.go#L202

This is however non portable as stated in the docs. I can live with that.
Can I break the gathering of uid, gid, and mode into separate files
(fi_linux.go, fi_darwin.go, etc) and build them conditionally based on
target OS? Is this even sane?


--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Albert Strasheim at Oct 10, 2013 at 1:12 pm

    On Thursday, October 10, 2013 1:03:44 PM UTC, Kelsey Hightower wrote:

    After searching this mailing list and reading the syscall package docs,
    I've come the obvious conclusion that gathering the uid, gid, and mode of a
    file is not possible outside of the syscall package -- well if I want to
    stick to the stdlib.
    Here is what I'm trying to do:

    https://github.com/kelseyhightower/confd/blob/master/template_resource.go#L202
    This is however non portable as stated in the docs. I can live with that.
    Can I break the gathering of uid, gid, and mode into separate files
    (fi_linux.go, fi_darwin.go, etc) and build them conditionally based on
    target OS? Is this even sane?
    I think you're looking for +build flags.

    grep -r "// +build" $GOROOT/src/pkg


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kelsey Hightower at Oct 10, 2013 at 1:26 pm
    That looks like exactly what I want. Thanks.
    On Thursday, October 10, 2013 6:12:40 AM UTC-7, Albert Strasheim wrote:
    On Thursday, October 10, 2013 1:03:44 PM UTC, Kelsey Hightower wrote:

    After searching this mailing list and reading the syscall package docs,
    I've come the obvious conclusion that gathering the uid, gid, and mode of a
    file is not possible outside of the syscall package -- well if I want to
    stick to the stdlib.
    Here is what I'm trying to do:

    https://github.com/kelseyhightower/confd/blob/master/template_resource.go#L202
    This is however non portable as stated in the docs. I can live with that.
    Can I break the gathering of uid, gid, and mode into separate files
    (fi_linux.go, fi_darwin.go, etc) and build them conditionally based on
    target OS? Is this even sane?
    I think you're looking for +build flags.

    grep -r "// +build" $GOROOT/src/pkg
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Oct 10, 2013 at 5:56 pm
    Also, simply naming files with _<GOARCH> and _<GOOS> in them will also
    work, and was the older method of doing system based conditional
    compilation before the build tag system was created.

    eg:

    fi_linux.go => only builds for Linux targets
    fi_darwin_386.go => only builds for 32-bit intel Mac OS X targets
    fi_windows_amd64.go => only builds for 64-bit Windows targets

    Both systems are supported by the go tool, but the newer build tags are
    more flexible, and have a larger selection of criteria, such as go version,
    cgo availability, app engine compilation, and user proivded tags.

    Here are some things to note:

        - These features are provided by the go tool, not the lower-level 6g/8g
        compilers, so if you call the compilers yourself, the logic won't happen.
        - If you explicitly name a file on the command line, neither set of
        rules takes effect
        - The filename rule is checked first, and then if passing, the build
        tags, so you can't override filename rules with contradictory build rules,
        but they can work together.
        - Both sets of rules apply to any file type handled by the go tool, for
        example CGO, SWIG and assembly code files can also use these rules (quite
        important for assembly)
           - File formats that aren't text-based, such as .syso files can't use
           build tag rules, but still can use filename rules.
        - The build tag expressions will only work if correctly positioned in a
        go file, "go vet" will check the most common cases (you can use "go vet
        file.go" to make sure the named file is checked)
        - There is no "test" build tag, so you can't control which files are
        only used for testing via build tag expressions

    On Thursday, October 10, 2013 6:12:40 AM UTC-7, Albert Strasheim wrote:
    On Thursday, October 10, 2013 1:03:44 PM UTC, Kelsey Hightower wrote:

    After searching this mailing list and reading the syscall package docs,
    I've come the obvious conclusion that gathering the uid, gid, and mode of a
    file is not possible outside of the syscall package -- well if I want to
    stick to the stdlib.
    Here is what I'm trying to do:

    https://github.com/kelseyhightower/confd/blob/master/template_resource.go#L202
    This is however non portable as stated in the docs. I can live with that.
    Can I break the gathering of uid, gid, and mode into separate files
    (fi_linux.go, fi_darwin.go, etc) and build them conditionally based on
    target OS? Is this even sane?
    I think you're looking for +build flags.

    grep -r "// +build" $GOROOT/src/pkg
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kelsey Hightower at Oct 14, 2013 at 3:50 pm
    I ended up going with the file naming convention and it works like a charm.
    On Thursday, October 10, 2013 10:56:15 AM UTC-7, Carlos Castillo wrote:

    Also, simply naming files with _<GOARCH> and _<GOOS> in them will also
    work, and was the older method of doing system based conditional
    compilation before the build tag system was created.

    eg:

    fi_linux.go => only builds for Linux targets
    fi_darwin_386.go => only builds for 32-bit intel Mac OS X targets
    fi_windows_amd64.go => only builds for 64-bit Windows targets

    Both systems are supported by the go tool, but the newer build tags are
    more flexible, and have a larger selection of criteria, such as go version,
    cgo availability, app engine compilation, and user proivded tags.

    Here are some things to note:

    - These features are provided by the go tool, not the lower-level
    6g/8g compilers, so if you call the compilers yourself, the logic won't
    happen.
    - If you explicitly name a file on the command line, neither set of
    rules takes effect
    - The filename rule is checked first, and then if passing, the build
    tags, so you can't override filename rules with contradictory build rules,
    but they can work together.
    - Both sets of rules apply to any file type handled by the go tool,
    for example CGO, SWIG and assembly code files can also use these rules
    (quite important for assembly)
    - File formats that aren't text-based, such as .syso files can't
    use build tag rules, but still can use filename rules.
    - The build tag expressions will only work if correctly positioned in
    a go file, "go vet" will check the most common cases (you can use "go vet
    file.go" to make sure the named file is checked)
    - There is no "test" build tag, so you can't control which files are
    only used for testing via build tag expressions

    On Thursday, October 10, 2013 6:12:40 AM UTC-7, Albert Strasheim wrote:
    On Thursday, October 10, 2013 1:03:44 PM UTC, Kelsey Hightower wrote:

    After searching this mailing list and reading the syscall package docs,
    I've come the obvious conclusion that gathering the uid, gid, and mode of a
    file is not possible outside of the syscall package -- well if I want to
    stick to the stdlib.
    Here is what I'm trying to do:

    https://github.com/kelseyhightower/confd/blob/master/template_resource.go#L202
    This is however non portable as stated in the docs. I can live with
    that. Can I break the gathering of uid, gid, and mode into separate files
    (fi_linux.go, fi_darwin.go, etc) and build them conditionally based on
    target OS? Is this even sane?
    I think you're looking for +build flags.

    grep -r "// +build" $GOROOT/src/pkg
    --
    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/618c93d2-3db2-46a4-8ca4-229c9d3d455f%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 10, '13 at 1:04p
activeOct 14, '13 at 3:50p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase