Re: [dev] make framework for wmii

2009/5/26 Kris Maglione <maglione.k_AT_gmail.com>:
> On Mon, May 25, 2009 at 11:38:47PM +0900, KIMURA Masaru wrote:
>>
>> I'm now browsing wmii hg2467.
>> a) default config.mk has X11PACKAGES=xft and INCX11=$$(pkg-config
>> --cflags $(X11PACKAGES))
>> b) cmd/Makefile has redundant $$(pkg-config --libs $(X11PACKAGES)) w/
>> hardcoded -lXext
>> c) cmd/click/Makefile has hardcoded -lXtst in LDFLAGS
>> d) test/Makefile has $(LIBX11) and w/ hardcoded -lXext in LDFLAGS
>>
>> Folks, could you mind to explain why they are?
>> My point is,
>> a) X11PACKAGES and INCX11 is a bit global. It can be hide into
>> separated Makefike fragment like other X libs.
>> b) $(LINK) has $$(pkg-config --libs $(PAKCAGES)) in mk/hdr.mk.
>> c) Ditto
>> d) Ditto
>
> The pkg-config bit is new and therefore rough. I may not even keep it, and
> if I do, it'll certainly look significantly different than it does now. As
> for cmd/Makefile, the pkg-config fragment isn't redundant, it's there
> because not all programs in cmd require X11. I may add an x11 subdirectory
> to handle the distinction.

O.K. Sorry for poking half-baked one. Like you said, separating X11
dep is a way to go.
BTW I also interested in p9p's AUTOLIB approach, so any technical
reasons why you didn't embed/get library dependency into/from source
files themselves? A while ago, I did grep #included X11 headers in
wmii source code to see real X11 dep b/c X11 was becoming modular, and
I got it.

>> To tell you the truth, I've been being confused about Kris' make
>> framework for wmii.
>> In the past, I saw Anselm's Makefile for wmii, it was straightforward to
>> me.
>> Or, should I do self-enlightenment by reading some articles related mk?
>
> The old makefile may have been straightforward, but it was also bulky. Every
> directory needed its own, complete set of build recipes, most of which was
> redundant and generally superfluous. When I start writing a new program or
> library, I don't like to cut and paste huge chunks of code, when I make
> changes, I don't like to make them in 10 places, and when I read a makefile,
> I like to see only the relevant bits of information (what objects I'm using,
> what libs I'm linking, what extra compiler flags I need). wmii's build
> system *is* based on Plan 9's system mkfiles, and is admittedly a lot nicer
> when written in mk. I'll admit though that it's grown by accretion to the
> point that it needs some serious cleanup.

I see your point that almost of unnecessary code dup doesn't make sense.
OTOH, new make framework has also every directory its own, incomplete
set of build recipes, most of which was scattered and tricky. When you
start to writing a new one w/ bulkly Makefile, all you need to do is
just copy'n'paste and edit source/target name or so. Changing existing
make frame work drastically is so rare. But yes, your consider may be
right wmii has now over 15 files which was named Makefile. If just
seeing 1 Makefile is enough to get complete information about their
build, I think it could be right in a way. Plan 9 is good, wmii is
featuring 9ish, it's good. But saying "Plan 9's is best" means the end
of fooling around w/ software for me.

Anyway, I should and would like to check mk thingy to get 9ish points
for myself.

Thanks,

[SNIP]
Received on Mon May 25 2009 - 17:24:36 UTC