I love your sense of humour, is it hosted on github by any chance?
On Sun, 8 Jan 2017 02:05:14 -0600 "Matthew D. Fuller" <[email protected]> wrote: > On Sat, Jan 07, 2017 at 12:55:59PM -0500 I heard the voice of > David Niklas, and lo! it spake thus: > > > > I'm including a dump of my build so you may verify the results I > > got. > > Huh. Well, that's very interesting. Let's look at the sound question > (similar points could be made for m4, but sound has more of 'em to > make). > > > When USE_SOUND is set for imake, it winds up adding -DSOUNDS to the > compiler args, adds the -L/whereever and -lrplay to the linking args, > and adds sound.c to the list of source files worked with and linked > in. > > So in your log: > > x86_64-pc-linux-gnu-gcc [...] -c -o sound.o sound.c > > Compiled. Check. > > x86_64-pc-linux-gnu-gcc -o ctwm [...] sound.o [...] -L/usr/lib64 -lrplay > > Linked in and linked to librplay. Check. > > > `ctwm -info` would use the -DSOUNDS to add 'SOUNDS' to the output. > Assuming everything's installed correctly by the process so you're > running the newly-build program, it'll be there. It has to be, > because we had -DSOUNDS in all those compiler lines. I mean, it's > right there: > > x86_64-pc-linux-gnu-gcc -pipe -O2 [...] -frecord-gcc-switches > -DXPM -DJPEG -c [...] > > It's right in the... it's at... before the... wait. Oh, I see > it, it's right beside the -DUSEM4 that enables m4, right at the... > uh... > > > So, imake is getting the right bits, or you wouldn't be linking in > sound.o and librplay. But somehow the -D flags aren't getting set > right. Now, that could be done by editing and mucking up the > Imakefile bits. That seems stupid and unlikely. I don't have any > real knowledge of ebuild stuff, but I do glare somewhat suspiciously > at: > > src_configure() { > append-cppflags -DXPM -DJPEG > xmkmf || die > } > > in it. It's deeply suspicious that those hardcoded -D's there are the > only ones showing up in the compile lines. And that shouldn't be > hardcoded by the build control anyway; if those aren't getting set > right by the imake process, there's a problem somewhere in THERE, and > THAT'S where it would need to be fixed, not by adding another level of > hack on top. Maybe the way CFLAGS are set in the emake line in > src_compile() is blasting over what imake is trying to use itself? > > > > (I know, you dislike binary files, but it's going to be 100K message > > otherwise). > > Oh, I'm perfectly happy with compression. It's slightly less > convenient, but a lot smaller; the build log is big enough it's an > easy tradeoff. > > > > I'd really love to contribute, but I've[1] already[2] over[3] > > extended myself. > > That's never stopped you or any of the rest of us in the past. I > mean, it's not like you really have to sleep EVERY day, right? ;) > Nah, I sleep at night. I tried building ctwm from source by hand and I got the error where imake.tmpl cannot be found. I searched the web to find out how to invake imake (I did try substituting a copy of Imakefile.local-template, it works, but then make has not build targets), and I found, via the faq, that you're supposed to invoke -- get ready for this -- xmkmf! I take it that you did not read the imake book or build the actual imake system used by ctwm. Don't fret, I'll use the unstable version, when it's stable, I'll promulgate it to Gentoo. Thanks, David
