On Sat, 20 Mar 2010, Carlos R. Mafra wrote:
> > It is not connected to wmaker, but when someone adds platform
> > detection to the autohell stuff, this can easily be integrated.
>
> I hope there is some brave BSD person with enough courage to go to
> hell, do the autoconf stuff there and come back to tell the story
> and show us the patch...
i was rather thinking sir raorn but well :) one thing is for sure, i
am not touching that with a six-feet pole. on the other hand, bsd
ports-maintaining people can easily patch this up in their build
frameworks, so adding this even unconnected and just hanging still is
worthehile. imho. but then, i'm of course partial ;)
> But I see your point, in showing what should be done. Perhaps add a line
> to TODO?
saying what? i'm not sure what you are referring to.
> > + if (GetCommandForPid(getpid(), &nargv, &nargc) == False) {
> > + printf("GetCommandForPid() failed\n");
>
> Did you see this failing in some BSD with the current (linux)
> GetCommandForPid()
> and not failing when using the new osdep/bsd.c file?
it always* fails on bsds. it always fails *everywhere else* too. it
always has. which leads me to question the utility of all this, but
then i'm thinking, if it's in, there must be shitty clients needing
this.
* except on netbsd, where a (sufficiently linux-compatible) procfs is
mounted by default; or if you mount one on any other that provides a
sufficiently linux-compatible procfs implementation.
> Is there someone else out there who can test this?
yes, yes. indeed. do test.
> > + osdep/linux.c \
> > monitor.c \
>
> A small nit. I've just noticed that the compiled linux.o is inside
> src/ instead of src/osdep/
this is quite expected. proper autostuff integration and all that...
--
[-]
mkdir /nonexistent
--
To unsubscribe, send mail to [email protected].
