The most common formats for config file are json, yaml and etc.
When we use this formats, we need to open the file and parse it into structure.
Can we declare config like a new go package and export necessary data by variables? Are there any problems or pitfalls?
The main disadvantage is that you have to ship the Go compiler and linker as part of your configuration system, because in order to load a configuration file, you have to compile the configuration file and link it into the application.
You also have to make sure that the ABI of the compiled configuration file is compatible with the ABI of the application.
Related
i am looking for a build tool that allows me to store the build tool with additional pre and postscripts as well as the build configs in folders separated from the source code.
Most build tools i tried work with config files directly in the source code folder.
Could you recommend something?
I know that it sounds like i am missusing the concept and should simply insert config files in the source code folder. Yet the reasoning behind this will blow up this post without adding a lot of value.
SCons can do it several different ways.
Though Repository() might be the simplest.
See: https://scons.org/doc/production/HTML/scons-user.html#idm46358268990080
How to inspect the content of Go package/object files (.a, .o)
The only thing I found is showing the full disassembly with go tool objdump.
But how to show the file structure, like imported and exported symbols, code, data and other sections, other metadata etc.?
Compiled Go packages are stored in Unix ar archive files, so you can extract the files within them using ar or go tool pack x pkg.a.
Package files contain compiled code (_go_.o), used by the linker to build binaries, and export data (__.PKGDEF), used by the compiler when building dependent packages. If the package contained assembly files or cgo code, there may be additional .o files, too.
You can use golang.org/x/tools/go/gcexportdata to read export data into a format that can be understood by go/types.
It sounds like you've already found go tool objdump for disassembly. You might also find go tool nm useful for listing symbols.
I have a simple go server that works, and gets most of its configuration settings from a toml file.
The current process involves restarting the go build source every time the settings are changed.
What is the correct/most preferred/tested and working way to ship only binary and the config.toml file?
I am still a newbie when it comes to compiling, and i have been reading a lot of texts and still not having a clear understanding on this issue.
Any useful comments will be appreciated.
Config files aren't meant to be embedded in executables. It'd be better to have them reside alongside executables. Since I couldn't get your point on rebuilding complete app just for reloading configuration, I made up my former sentences presuming you're hardcoding.
If we get to the “reloading” topic, I would surely restart my program or send a signal to re-load the configuration. You don't have to do this, because there is a nice library doing this: https://github.com/spf13/viper. It is easy to use and supports live watching for changes on config file. Besides supporting JSON, YAML, TOML and HCL, it can read from environment variables, remote config systems (like Consul and etcd). It's trusted and used by big projects, such as Kubernetes.
How can I change the default location of the folder in which the compiled object files are stored when using Gradle for compiling c sources?
Right now, the objects are created in build/objs/path/of/object_files. How do i change it to some location within my source file hierarchy? And how do i convey this information the linker (if required)?
Also as a note, I do not use the default Gradle convention source file hierarchy. And I use GCC compiler and linker (sparc-rtems variant).
I don't think it is possible as this will go directly against Gradle model design.
The whole point of the new software model in Gradle is to be declarative. Model should only describe what needs to be done, not how. Once you need to access the object files, you need to know implementation details.
I need to dynamically generate some macros into a .h configuration file that C programs can include in order to check which options are enabled, in a fashion similar to what is possible with CMake's CONFIGURE_FILE macro. But after looking in the doc and the web, I could not find something useful. Is it possible to generate such a file from bjam and have the dependencies handled correctly? If so, how would you do it?
Yes it's possible.. The way to do it boils down to defining a make target for the header and using the #() file output action support in bjam. You would set up a set of configuration variables on the header target and the action would use them to generated the file. That is what I do in one of the library extensions I wrote (see GIF lib extension). I also wrote some basic support for automating some of the tasks, but it still ends up being functionally the same, to create text files in the ext.jam utility. To allow easier definition of header configuration files that change based on Boost Build features (see Irrlicht 3D lib extension). Basically you can do just about anything you can think of with the make target since it's implementation is entirely up to you.