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.
Related
I am developing an OS for embedded devices that runs bytecode. Basically, a micro JVM.
In the process of doing so, I am able to compile and run Java applications to bytecode(ish) and flash that on, for instance, an Atmega1284P.
Now I've added support for C applications: I compile and process it using several tools and with some manual editing I eventually get bytecode that runs on my OS.
The process is very cumbersome and heavy and I would like to automate it.
Currently, I am using makefiles for automatic compilation and flashing of the Java applications & OS to devices.
All steps, roughly, for a C application are as follows and consist of consecutive manual steps:
(1) Use Docker to run a Linux container with lljvm that compiles a .c file to a .class file (see also https://github.com/davidar/lljvm/tree/master)
(2) convert this c.class file to a jasmin file (https://github.com/davidar/jasmin) using the ClassFileAnalyzer tool (http://classfileanalyzer.javaseiten.de/)
(3) manually edit this jasmin file in a text editor by replacing/adjusting some strings
(4) convert the modified jasmin file to a .class file again using jasmin
(5) put this .class file in a folder where the rest of my makefiles (the ones that already make and deploy the OS and class files from Java apps) can take over.
Current options seem to be just keep using makefiles but this is a bit unwieldly (I already have 5 different makefiles and this would further extend that chain). I've also read a bit about scons. In essence, I'm wondering which are some recommended tools or a good approach for complicated builds.
Hopefully this may help a bit, but the question as such could probably be a subject for a heated discussion without much helpful results.
As pointed out in the comments by others, you really need to automate the steps starting with your .c file to the point you can integrated it with the rest of your system.
There is generally nothing wrong with make and you would not win too much by switching to SCons. You'd get more ways to express what you want to do. Among other things meaning that if you wanted to write that automation directly inside the build system and its rules, you could also use Python and not only shell (should that be of a concern though, you could just as well call that Python code from make). But the essence of target, prerequisite, recipe is still there. And with that need for writing necessary automation for those .c to integration steps.
If you really wanted to look into alternative options. bazel might be of interest to you. The downside being the initial effort to write the necessary rules to fit your needs could be costly. And depending on size of your project, might just be too much. On the other hand once done with that, it'd be very easy to use (apply those rules on growing code base) and you could also ditch the container and rely on its more lightweight sand-boxing and external rules to get the tools and bits you need for your build... all with a single system for build description.
I've been tasked with adding features to an existing hyperledger system. But all I've been given is the .bna file. I can clearly see it contains javascript source as well as models, but is this really enough to develop from? All my experience is going from .cto and .js files and configs to building the .bna archive. How do I go about doing that in reverse? Am I likely to run into problems because I'm missing something necessary not normally packaged in the .bna? Should I insist on getting the actual source tree that was used to build the .bna file? I already asked specifically for that and NOT the .bna file, but was ignored. Am I the ignorant one here?
The BNA file contains everything the networks needs to execute. The only things you are missing is things like build scripts, unit and system tests, documentation. So, I would keep trying to get the original source if you can, if you can't you do have enough to get going.
I'm working on updating the Neo4j windows installation process into Powershell and I was thinking that perhaps it could read/write neo4j windows service information from the neo4j-wrapper.conf configuration file.
The Windows wrapper conf has very little information that is related the windows service itself (in fact I think it has no information that is used in the creation, management and removal process!)
My intention is to have the relevant windows service information in the configuration file and then when calls such as Install or Stop are made, then the Service Name can be retrieved from there instead of via command line arguments.
My questions are;
If I put more information into that configuration file, will it affect the linux wrapper?
Is there any reason why I shouldn't put more settings into the configuration file (but only related to a Windows Service)?
Note - My changes would also support this PR;
https://github.com/neo4j/neo4j/pull/4433
Thanks,
Glenn.
I think the answer is, in principle, yes. Putting extra stuff in that file wouldn't hurt anything.
But it's not ideal to have a single file that's used for different purposes on different platforms (I see the presence there of Linux-specific service stuff as a problem rather than something to copied).
The real solution, I think, is for each package build to provide its own copy of that file (or one derived from a common starting point).
I'd like to create a dot file to hold the configuration for an app I've created.
I've seen this https://github.com/mattdbridges/dotify which is no longer maintained and this https://github.com/GRoguelon/DotConfig which appears to still be in alpha.
It seems I'd be best off managing this manually (i.e. writing the code myself).
Any better suggestions?
If possible, I recommend using YAML (http://www.yaml.org/YAML_for_ruby.html) to write, load, and read your config files.
For example, I don't want to overwrite the config file and some other files,What should I do using WiX?
Assuming your files are just text/xml the default behaviour of MSI would be to notice that they are unversioned and have been changed since last install and therefor they will be skipped on upgrade. See MSI File Replacement logic.
Now if your config file has changed between releases (add/removed some options) you'll need to do something to upgrade the file while saving the previously edited values. That gets a little trickier.
Take a look at:
StackOverflow - Manage configuration files with wix
If this is user settings for an application I would tend to agree with Rob Mensching (the main WiX guy) in the post above, that it would be better to have the app handle its own config and the updates to it.
However this doesn't work well if it is the config file for a service or something that should not be writing to its own config file. You are usually left with writing custom actions to manually handle this scenario. fun times. ;)