David Brownlee <abs%absd.org@localhost> writes: > We have some... different patterns in naming mk files that can pull in > different dependencies > > I'm not looking to necessarily change any existing files here, more to > see if there is consensus on which of the patterns are encouraged, and > hopefully document that. It's an interesting list. > Pattern 1 - dependency selection - in package dir with various .mk files > - All files live in package dir > - Good example is lang/python with application.mk, egg.mk etc, all > calling pyversion.mk and checking PYTHON_VERSIONS_* and friends, python is an example where there is only on upstream and there are multiple versions. And, lang/python is only about selection and not in lang/Makefile. I don't want to rock the boat, but this is an odd setup and I would prefer not to replicate it. > Pattern 2 - dependency selection - various .mk files in pkgsrc/mk > - pretty much the same as pattern 1, except the files live in pkgsrc/mk > - java is a good multi file example with java-env.mk and java-vm.mk > with PKG_JVM_DEFAULT, USE_JAVA2 (sic) and friends, or apache with > apache.mk, apache.module.mk and PKG_APACHE_ACCEPTED etc > > Pattern 3 - dependency selection - various buildlink3.mk files in pkgsrc/mk > - pretty much the same as pattern2, but with a 'buildlink3.' in the filename > - good example would be bdb, with bdb.buildlink3.mk and BDB_ACCEPTED etc I see 2 and 3 as amounting to the same thing, and sort of lean to labeling them buildlink3, unless I suppose they don't end up interpolating bl3. It seems pattern 3 is more common. > Pattern 4 - factored out build config in pkgsrc/mk > - "one of these things is not like the others..." named the same as > pattern2, but just holds build config as opposed to dependency > selection (with associated build config) > - example would be djbware.mk > > Pattern 5 - builtin handling - always(?) named *.buildin.mk in pkgsrc/mk > - determines whether to use builtin or pkgsrc dependencies > - usually not used directly, but called by a buildlink3.mk file > - example - mk/readline.builtin.mk, called by readline.buildlink3.mk I think it's always foo.builtin.mk next to foo.buildlink3.mk whereever it is, and there is some of this for packages that are the only one of their kind. > There is also the minor issue that these are all mixed in with the top > level mk files in pkgsrc/mk - which adds to the level of confusion to > anyone coming new to the pkgsrc setup true, but putting them in subdirs is minor issue with much ansgst, trading off churn cost with future clarity. > So > > a) I think the biggest inconsistency seems to be between pattern 2 & 3 > - which seem to pretty much be the same thing. At the very least > should the dependency selection mk files have buildlink3. in their > names, and can we document a recommendation going forward For thinks that actually end up doing bl3, I think we should call it buildlink3.mk. For things that add DEPENDS lines and don't include a bl3, maybe we should use foo.depends.mk instead. But, I am skeptical that once we talk about selecting 1 of N, that it will continue that none of them are bl3 in the end. > b) If we are happy keeping both 1 and 2/3 for new files going forward, > can we document a preference for how to name them. eg: If it applies > to a single named package, put it in the package dir, else if it's > more general put it in pkgsrc/mk. I'm half inclined to say 'prefer > putting everything new in pkgsrc/mk', but I can see arguments against I think if there's a package that can be pkgsrc or builtin, and there aren't N variations of the package (alternative ways to provide an API), then being in the package dir is good. Basically, files like this in a package dir shouldn't be reaching to other packages. Otherwise, mk. So I think I mostly agree with you. > c) subdirectories? if we're going to keep adding files to pkgsrc/mk > can we get these types of files into one or more subdirectories (OK, > maybe I _am_ looking to change existing file layout here) We could put all this stuff in mk/depends/ instead of mk/, and maybe for now just put new things there. I certainly don't want to rototill and be responsible for fixing the inevitable breakage. Back to point, I think I prefer ssl.buildlink3.mk that has a package-settable SSL_ACCEPTED and a user-settable preference variable, and awareness of rules e.g. like security/openssl and security/openssl3 can't be installed simultaneously, but openssl and security/gnutls can be installed simultaneously. I think I prefer this even if the first incarnation is only about openssl/openssl3. The most similar existing case I can think of is probably bdb, with different APIs and a culture of packages being able to cope with various versions. But that's all one upstream and many versions, and I think libraries to do openssl are far broader. Still, I expect many packages to be able to cope with more than one of them.
Attachment:
signature.asc
Description: PGP signature