building master about skippy-xd HOT 9 CLOSED

Yes, if you are not building directly from the git directory, and you didn't specify SKIPPYXD_VERSION yourself, you may get those messages. The outcome is skippy-xd will not print the correct version number, but nothing more serious as far as I know.

By the way, I have a patch in #2 that needs some test. I'm still too busy on my 40-page thesis and various annoying things in compton, so probably I can't merge the patch inside very soon.

from skippy-xd.

I see. Could you give an example on how to specify SKIPPYXD_VERSION ? Thanks.

Also, isn't this message worrying:
src/wm.c: In function ‘wm_get_window_title’:
src/wm.c:400:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]
src/wm.c: In function ‘wm_wid_get_prop_rstr’:
src/wm.c:656:3: warning: pointer targets in passing argument 1 of ‘mstrdup’ differ in signedness [-Wpointer-sign]
src/skippy.h:299:1: note: expected ‘const char *’ but argument is of type ‘unsigned char *’

And lastly, is it OK to drop the libXmu dep from the packaging?

from skippy-xd.

Oh, so soon you are packaging it? Thanks! :-)

I see. Could you give an example on how to specify SKIPPYXD_VERSION ? Thanks.

export SKIPPYXD_VERSION=git-cdd06a9-2013-04-30 before you run make, or specify SKIPPYXD_VERSION=git-cdd06a9-2013-04-30 as an argument to make. Basically the format isgit-<REVISION>-<DATE>.

Also, isn't this message worrying:
src/wm.c: In function ‘wm_get_window_title’:
src/wm.c:400:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]
src/wm.c: In function ‘wm_wid_get_prop_rstr’:
src/wm.c:656:3: warning: pointer targets in passing argument 1 of ‘mstrdup’ differ in signedness [-Wpointer-sign]
src/skippy.h:299:1: note: expected ‘const char *’ but argument is of type ‘unsigned char *’

No, it's harmless. I've already suppressed them in the patch mentioned above.

And lastly, is it OK to drop the libXmu dep from the packaging?

I don't see libXmu in the debian control file. (The Debian control file seemingly needs a lot of work.) But yes, libXmu is not needed. I have no idea why it was there.

from skippy-xd.

Well, again my commit has to be delayed because:

1. There's one memory corruption bug in config_parse(). Already implemented a fix.
2. There's a bug in FIFO flush code that the first command sent through an existing pipe is ignored. Already implemented a fix.
3. The daemon thing looks horribly broken. The author apparently ignored the high probability of window ID reuse (which a stupid problem of X server, though) and various other things. I would recommend lifting out the daemon design as I don't think it is practically useful. It doesn't actually fix those issues but at least it evades them then. What do you think?

from skippy-xd.

"I don't see libXmu in the debian control file. (The Debian control file seemingly needs a lot of work.) "

For the PPA I use a different conotrol file. It looks much nicer: https://launchpad.net/~landronimirc/+archive/skippy-xd/+files/skippy-xd_0.5.1~hg20111223-1~precise~ppa3.debian.tar.gz

from skippy-xd.

OK, I've just set up the PPA for daily builds. It still needs testing to see if everything is as expected: https://code.launchpad.net/~landronimirc/+recipe/skippy-xd-daily

from skippy-xd.

What are the drawbacks of not having a daemon design?

from skippy-xd.

@landroni:

Sorry, recently I probably won't have time to work on this. I'm trying hard to find a job... (Apparently my knowledge about Linux, Xlib, and OpenGL is pretty much useless when looking for a job... So I'm working hard on learning Linux kernel designs as well, in hope it will bring me some extra luck.)

OK, I've just set up the PPA for daily builds. It still needs testing to see if everything is as expected:

Great! :-)

What are the drawbacks of not having a daemon design?

What I know is daemon mode is slightly faster for activation -- but very slightly, I assume.

from skippy-xd.

"What I know is daemon mode is slightly faster for activation -- but very slightly, I assume."
I've now tested the PPA and it works fine. Also the new code seems quite reliable; no crashes so far. And execution doesn't feel particularly slow. All in all, very nice.

from skippy-xd.