From 8b2f8a458e60d66685741a4fd638f2ec89dff979 Mon Sep 17 00:00:00 2001 From: rillig Date: Sat, 4 Feb 2006 04:10:12 +0000 Subject: Pinned down the collected problems of the current pkglint development. --- pkgtools/pkglint/README | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 pkgtools/pkglint/README diff --git a/pkgtools/pkglint/README b/pkgtools/pkglint/README new file mode 100644 index 00000000000..17a920abf5b --- /dev/null +++ b/pkgtools/pkglint/README @@ -0,0 +1,33 @@ +$NetBSD: README,v 1.1 2006/02/04 04:10:12 rillig Exp $ + +== Current problems == + +The current pkglint architecture will not scale much further. What is +needed next are parsers for nested, non-context-free languages (make(1), +sh(1), sed(1)). The parsers should be able to recognize partial +structures, as well as structures containing foreign parts. This is +because most of pkgsrc is heavily based on preprocessors: + +- The .if and .for directives in Makefiles are preprocessed by make(1) + before building dependencies and shell commands out of the remaining + text. + +- make(1) assembles shell commands from literal text and variables like + ${PKGNAME}. + +- Shell commands often use dynamic evaluation of variables. + +All this makes enhancing pkglint non-trivial. If you know of any +academic papers that might be of help in this case, please tell me. + +Additionally, the Perl programming language is not well suited to this +kind of tool. It does not provide: + +- Sufficient static checking (especially for names of methods) +- A type system (you can apply almost any operator to any kind of data) +- Object orientation (needed for the future advanced parsers) +- Narrow scope for constants (it's just ugly) +- Enumeration data types +- Structured data types + +The pkglint source code is much too big for a single file. -- cgit v1.2.3