On Fri, Sep 18, 2020 at 10:49:23AM +0200, Mohammed Hawari wrote: > Similarly to the disable_drivers option, the disable_libs option is > introduced. This allows to selectively disable the build of elements > in libs to speed-up the build process. > > Signed-off-by: Mohammed Hawari <moham...@hawari.fr> > ---
While I don't particularly like allowing libs to be enabled and disabled since it complicates the build, I can see why it's necessary. This is an area that does need some discussion, as I believe others have some opinions in this area too. However, for now, some additional thoughts, both on this patch and in general: 1. I see you included disabling apps if their required libs are not available. What about the drivers though? 2. A bigger issue is whether this is really what we want to do, guarantee a passing build even if vast chunks of DPDK are actually enabled? I'd tend towards "no" in this case, and I'd rather see disabling of libs more constrained. 3. To this end, I think I'd rather see us maintain a set of libs which are allowed to be disabled, and prevent the rest from being so. For example, it makes no sense in DPDK to disable the EAL or mempool libs, since nothing will build, while the bitrate_stats or latency_stats libs could likely be disabled with little or no impact. Therefore, I think a better implementation is to start as in this patch with a new config parameter to disable libs, but as part of that patch add in an internal list of the libs which are allowed to be disabled (initially empty). Telling the build system to disable a lib not on that list should raise a configuration time error. As for how a lib gets on the list - that should be done once the build has been tested with that lib disabled, i.e. once testpmd and other apps have got #defines in the code for stripping out the disabled blocks, and any drivers which depend on the lib have proper checks and warnings in place about it being disabled (or also #defines in the code if that can be done). The other advantage of maintaining such a list is that it then becomes somewhat feasible to test these build settings, in that (maybe once per release), iterate through the list of disable-able libs and test that the build passed with each one disabled individually. [I think for this purpose we can ignore interactions of having two disabled simultaneously, in order to have something testable] What do others in the community think? Regards, /Bruce
