On Tue, Aug 30, 2016 at 12:35:31AM +0000, p...@wrada.com wrote: > Would you expect that everyone that writes a new core package, would add > their init code to sys/sysinit package and include their package in the > dependencies for sys/sysinit? Would that mean that if I include > sys/sysinit as a dependency in my app (every app probably would), it > automatically becomes dependent on all packages, or would this be special > somehow and not be necessary.
I think the sysinit package should have access to all packages in the build. Newt would have to do some magic to arrange for this (perhaps a setting in the pkg.yml file). The sysinit package wouldn't explicitly depend on these packages, it would just use whatever is already getting pulled in. > Does it make sense to have the sysinit.yml file include the "init method > name² for the package and have newt build that sysintit.c file special for > your target? This has the advantage that we are not coupling these > projects together or using tons of ifdefs which make the code hard to read > (its hard to teach my idea about defines that newt creates). It raises the > issue of order though since we can¹t enforce an order if its generated > like this. We would also have to make these a fixed prototype to make it > easy (I think it would be easy to make the int foo(void)). That is not a bad idea at all. It does bother me that sysinit needs code to initialize every core package, and this seems like a good solution to that problem. You are right about the ordering issue. One option is for each system package cto have a numeric "stage" setting. The sysinit code would initialize every package in stage 1, before those in stage 2, and so on. Within a stage, packages would be initialized in alphabetical order (or whatever). > Would non-core packages put their init code in sys/sysinit? Or is this > just for os-core stuff? I think if non-core packages can leverage the sysinit feature, then they should. I was thinking it would just be core packages because sysinit would need special code for each package. However, you init function idea might be a way to solve this issue and allow other packages to use it. > My preference is to put some thought into the yml file format for future. > We¹ve got tons of packages and its may be a pain to make a drastic change > later. We don¹t need to add the features now, just make sure the yml file > has the hierarchy to support the things we are thinking about now. Thanks, Chris
