>From: Development <[email protected]> on behalf of Jedrzej >Nowacki <[email protected]>
>Personally, I also do like the idea of monolithic repo, while keeping >modularization on the logical / build level. In our current state I see two >major problems: >- our build is quite monolithic in practice. For example qtbase always needs >to be build. CI currently caches builds on repository level (caches results of >make install) with monolithic repository the optimization would need to be >reconstructed on the build level. Conceptually it is good, but someone would >need to do the work. >- as a consequence of a partial build, the repository may be in a broken >state, for example not compiling. It can be solved by time based world >rebuilding and tagging known good revisions, but some policies would need to >be created. I am clearly missing something here. Could you please outline why such a monolithic repo would be good? As you pointed out yourself, the conceptual problem that different libraries won't walk in lockstep remains and segmented builds continue to be desired. Sure, repo checkout is easier but as long as segmentation exists I fail to see the advantage. -- Alex _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
