User Details
- User Since
- May 10 2014, 6:48 PM (522 w, 5 d)
Mon, May 13
Sat, May 4
Fri, May 3
Vlad, there is no need in making option for everything. Instead, try to minimize list of options when creating ports. Group similar functionality under single option (or use RADIO/MULTI etc), don't make options for features that require light or common dependencies, especially if a feature does not need deps at all. Sometimes having too many options is worst than having no options.
And of course these are not 100% strict rules.
Mon, Apr 22
Apr 12 2024
Apr 11 2024
Apr 9 2024
Apr 8 2024
Apr 4 2024
Rename cmake:noconf to cmake:indirect
Apr 3 2024
Mar 29 2024
Mar 28 2024
Apply Ade's suggestions and convert a couple of ports for example.
Mar 27 2024
/
This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core. Secondly, cmake:noconf allows ports to use CMAKE_* helpers from cmake.mk, although I don't know whether pep517 (or meson, cargo, etc.) should use them, but several ports which use cmake for a side target could be simplified.
Mar 26 2024
Update diff with full context.
Mar 6 2024
Feb 22 2024
Around 500 ports define TEST, DEBUG, LTO options. What are implications for them?
If some subpackages have been disabled via options, should we force to build them anyway if they are listed in TARGET_SUBPACKAGES? What if other ports rely on particular subpackage?
Feb 19 2024
Add @qt5
trim patch