Enrico Weigelt wrote: > > Imho, Kconfig would be good for more programs than it's currently used for, > > and could be made to work with those --enable/--with options: you'd be > > able to configure them entirely on the command line, or interactively > > with "./configure --menu" (runs menuconfig), or with a config file. > > Yes, that would be fine. But for me the primary constraint is that > all switches/options can be specified by command line - otherwise > I'd need extra complexity for each package in my distbuilder tool. Yes, I agree with that. It's one of the nice things about Kconfig that you can use it with pre-specific config files, even when the config is from a different version and doesn't specify everything. Doing so as ./configure --enable/--disable arguments seems like a comfortable fit. > > > Perhaps it might even be possible to write a very small, portable, > > specialised alternative to Make which is small enough to ship with > > packages that use it? > > No, I really wouldn't advise this. Make tools are, IMHO, part of > the toolchain (in a wider sense). Once point is avoiding code > duplication, but the really important one is: a central point of > adaption/configuration. That's eg. why I like pkg-config so much: > if I need some tweaking, I just pass my own command (or a wrapper). > If each package does it's library lookup completely by itself, I > also need to touch each single package in case I need some tweaks. > I had exactly that trouble w/ lots of packages, before I ported > them to pkg-config. That's interesting, thanks. I have seen problems with pkg-config, but adding your own wrapper is a nice way to fix any of them :-) That said, if you can specify library lookup on the ./configure command line, that fixes a lot of problems of repeatability too. Only problem then is you don't always know _which_ options to pass on the ./configure command line, if you have a package build script, and a different version of the package. There's a tendancy to drift apart which manifests as silent mistakes, until some user reports a bug. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
