Currently, each of our modules depends on the build.sh file in its own folder
This causes code duplication - each module has a similar build file. At the same time, we also have a simple build process and have written some shell scripts for it.
Now we hope to unify the build:
The build depends on a unified build script (it may be located in the build folder), so that we don't have to worry about script errors when building each module
Optimize our startup process (bootstrap), we expect a standard process like this:
The remote configuration center address is provided by args
Now our program lacks an engineering implementation of program parameters. It only relies on a simple "flag" package. We should use a more engineering design.
Although we use a remote configuration center, the parameters mentioned above refer more to the options when the program is initialized. For example, we can set a useHook flag to decide whether to use eshook
tips: you can choose a suitable flag package or still use "flag" package
ozline
commented
1 month ago
Currently, each of our modules depends on the
build.shfile in its own folderThis causes code duplication - each module has a similar build file. At the same time, we also have a simple build process and have written some shell scripts for it.
Now we hope to unify the build:
The build depends on a unified build script (it may be located in the
buildfolder), so that we don't have to worry about script errors when building each moduleOptimize our startup process (bootstrap), we expect a standard process like this:
tips: you can choose a suitable flag package or still use "flag" package