[E-devel] General autofoo breakage in the absence of stuff it's SUPPOSED to be checking for.

[David S. <on...@gm...>]

On Thu, 12 Apr 2012 14:54:53 +0900 Carsten Haitzler (The Rasterman)
<ra...@ra...> wrote:

> On Thu, 12 Apr 2012 14:18:04 +1000 David Seikel <on...@gm...>
> said:
> 
> > On Thu, 12 Apr 2012 14:07:20 +1000 David Seikel <on...@gm...>
> > wrote:
> > 
> > > On Thu, 12 Apr 2012 12:57:10 +0900 Carsten Haitzler (The
> > > Rasterman) <ra...@ra...> wrote:
> > > 
> > > > On Thu, 12 Apr 2012 11:43:20 +1000 David Seikel
> > > > <on...@gm...> said:
> > > > 
> > > > > Starting from line 6048 of evas_object_textblock.c there is a
> > > > > macro defined BREAK_AFTER, that, in the absence of
> > > > > HAVE_LINEBREAK, refers to a non existant "str" array.  Yep,
> > > > > I'm trying to compile it on an embedded system that has no
> > > > > linebreak thingy (library?).
> > > > 
> > > > liblinebreak is there in src/static_deps and compiled along with
> > > > evas.
> > > 
> > > Sooo, why am I getting two errors that str is not defined?  
> > > 
> > > Fact is that the no linebreak path IS broken.  There is no str, I
> > > think it means to use the text variable instead.  I'm not so
> > > familiar with that bit of code though, so it might be something
> > > else.
> 
> dont disable liblinebreak. keep it. it's part of the evas srctree.
> you want it for intl suport.

I don't need intl support either.  Still does not get away from the
fact that it's broken without it.  The alternative macro looks like it
will do just what I need, if it could only reference the correct
variable.  Tried that, and it compiled at least, gonna test it tomorrow.

A three line macro used twice is WAAAAY smaller than an entire intl
line break library that I just don't need.  Don't think it will be too
hard to fix either, but I'm just not familiar with that code.

And yes, I've even stubbed out gettext, that's how little I need
intl.  :-P

> > Actually, in an effort to keep the embedded project small, I
> > disable as much as I can, including liblinebreak.  So that's why
> > I'm going through that path.  Which, as I said, is broken.
> > 
> > While I'm bitching, evas wants to include wayland stuff in the
> > build, so now I have to disable that to.  This is in my embedded
> > system, not even X.  I think that's where this error is coming from
> > -
> 
> have you looked at config.log ? it builds wayland_shm because it
> requires no wayland libs. wayland_egl requires egl - which you
> seemingly have or it wouldnt enable it. check config.log

If I had any sort of GL, then I would not be getting that error, coz
it's the lack of GL that the error is complaining about.  I build the
entire OS myself, it's got no GL.  Right now I have no config.log to
check for GL stuff, coz I just disabled all the wayland stuff to get it
to compile, so I could move onto the next bit of autofoo breakage.
 
> > In file included from evas_gl_private.h:3,
> >                  from evas_gl_context.c:1:
> > evas_gl_common.h:37:22: error: GL/gl.h: No such file or directory
> > evas_gl_common.h:38:25: error: GL/glext.h: No such file or directory
> > 
> > Coz the only GL that configure mentions is -
> > 
> > Engines:
> >   Software Memory Buffer.....: yes
> >   Software X11...............: no (Xlib: no) (XCB: no)
> >   OpenGL X11.................: no (Xlib: no) (XCB: no) 
> >   Software GDI...............: no
> >   Software DirectDraw........: no
> >   Direct3d...................: no
> >   OpenGL SDL.................: no 
> > 
> >   OpenGL Cocoa...............: no
> >   Software Framebuffer.......: yes
> >   DirectFB...................: no
> >   PSL1GHT....................: no
> >   Software 8bit grayscale....: no
> >   Software 16bit ............: no
> >   Software 16bit X11.........: no
> >   Software 16bit Directdraw..: no
> >   Software 16bit WinCE.......: no
> >   Software 16bit SDL.........: no (primitive: no)
> >   Wayland Shm................: yes
> >   Wayland Egl................: yes
> > 
> > Still wondering why the autofoo of so much of the current alpha
> > wants to include Exotic.h when it's not been built.  Hard for me to
> > debug that at the moment.  I just patch it out for now.

I'm taking a wild guess that the autofoo took one look at my qemu
pretending to be a x486 compile environment, says WTF, and thinks it's
exotic.  Still, why should it bother trying to include Exotic.h, when
Exotic is not even installed?  Exotic is still in PROTO, a release
tarball should NOT be depending on it for no apparent reason.

The edje autofoo was also thinking it should install multisense and ALL
it's friends, though I had none of that on this OS either.  Sure, alsa
is in the kernel, but no alsa development stuff, no remix, vorbis, or
any of that other stuff is anywhere near this OS.

Been up since yesterday, I'll sleep soon, and make a full report
later.  Seems to be a general lack of autofoo doing the right thing in
the absence of stuff it's supposed to be checking for.  That's kinda
what autofoo is FOR.

Still trying to figure out why the embedded system can't link my app to
ecore_exe stuff, though happily links to the rest of ecore.  You can't
even disable ecore_exe, and I actually need it.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.