n Sun, Mar 31, 2019 at 5:58 PM Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> Here is a list of things we should try to do: > I think there are two very different issues involved here, that don't really need the same solution: The OSv kernel's makefile, and the "apps" build system. > - Propose and define model app layout (Makefile, GET, ...) under > osv-apps > - Typically each app has GET shell script, Makefile and module.py: > - GET typically downloads ad puts source files into upstream > directory (sometimes using latest script) > - Makefile typically does what needs to be done (sometime > compiles) and puts source files into install subdirectory (sometimes > usr.manifest is generated, sometime usr.manifest is pre-defined). > - module.py is called to execute extra logic - sometimes to > generate usr.manifest, define cmdline and possibly multiple flavors > - This is somewhat documented in the README.md of osv-apps project > but is not clear enough and the apps are all over the place following > this > loose convention and I am myself guilty of not following it (see > python2x/3x apps that do too much in GET). I doubt it is worth fixing > existing apps but I think we could improve the documentation in this > area > and and possibly point to a good model app. > > I agree. Also note that the both the "GET" and "makefile" there are rather arbitrary conventions - all we need from the Makefile is to have the "make" and "make clean" target. That's it. Because people were too lazy to write a proper makefile around this requirement, "make" just calls "GET" which is a shell script that just does everything. We could easily have any other convention to build and clean a package. I think the more difficult part is understand what the heck is module.py and what is usr.manifest, etc. I think you're right that just documenting the conventions we used will go a long way in helping people to use this system, even if we don't change anything. > > - > - I know our build system (scripts/build and related python scripts) > is complicated enough. But it would be super nice to allow passing > parameters from scripts/build to app Makefile. The best use case for that > is building java9 (10,11,12 as well) JREs using jlink where it would be > nice to pass a list of JRE modules to incorporate - see > > https://github.com/cloudius-systems/osv-apps/blob/master/openjdk9-zulu-java-base/Makefile#L26; > I think there are many other apps that would benefit > > Possibly. Indeed if properly documented, it shouldn't matter that it's even more complicated. > > - > - Eliminate external - > https://github.com/cloudius-systems/osv/issues/743 > - It would be nice to detail what to do to each subdirectory (I am not > positive we want to eliminate all - see x64/acpica) > > I agree. We should do that. "external" is an idea that really outlived its usefulness, I think. Indeed we don't need to remove everything at once, we can do it piece by piece (and stop using pieces before actually removing them). > > - Convert to CMakefile > - I am not sure how difficult it would be, but one benefit of it > would be the ability to load a project in IDEs like CLion that are able > to > work with CMakefile, > > I would hate for this to happen. I really think OSv's makefile is well tuned and works well. Switching to cmake just to make an editor happy would be very sad. I don't know anything about clion, but is it possible to tell it OSv's include paths, etc., *without* switching the Makefile language? E.g., could we have "make clion" which automatically generates a file CMakeLists.txt which somehow includes the right incantations to tell CLIon what are OSv's include path and predefined macros needed to have the source files properly formatted? The file doesn't need to contain real instructions how to compile anything, I hope... > > - Some apps (like python2x/python3x) pull most of the binaries from > host instead of re-compiling from scratch. It would be nice to have a > shared app/tool to build apps from host like that. > > I agree. It would really be nice to have scripts or python code for module.py or something, of how to copy a bunch of files from the host and possibly the shared libraries they need, etc., and then just use this same script from various apps instead of repeating the same code (with variations nobody understands) in a dozen apps. > Feel free to add any other things you would like to be improved in the > build system. > > Waldek > > - > > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
