On Thu, 12 Apr 2012 10:18:19 +0300 Tom Hacohen <[email protected]> wrote:
> Fixed, in svn. > > Thanks. > > On 12/04/12 10:08, Tom Hacohen wrote: > > On 12/04/12 04:43, David Seikel wrote: > >> 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?). > > > > Odd. I haven't tested it in a while, but when I had, it was fine, I > > don't get why it would change. > > > > Anyhow, ok, I'm on it. > > > > As raster said though, it's a good thing to have. ;P Thanks for fixing it. Good to know my guess was correct about the fix. <rant> I'll say again though, if I'm not using it, for ANYTHING, then it's just a waste of space and time to have on this embedded system that needs to be as small as possible. I don't need intl, it's only ever gonna be used in English. I probably don't even need line breaking, but I don't know yet. If I do, a simple "Is this a space in ASCII?" is all I'll ever need. Since that's pretty much what I get if I --disable-linebreak, then it's important to me that it actually works. It's not a good thing to waste more time compiling stuff I don't need, especially when I sometimes have to compile it on a x486, or qemu pretending it's a x486. The more time I can shave of those 9 hour compiles, the better. The smaller I can make it, the better. The less code the government testing labs have to deal with, the better. There are many reasons why I should get rid of stuff that's entirely useless for this specific project. Especially if it's just a --disable-foo to get rid of it. I do wish people would stop telling me "Oh just include this, and just include that, it's all good". I'm the one that knows what the specs are for this job, and I'm the one that has to shave off as much useless stuff as is reasonable. I get to decide what goes and what stays based on my knowledge of the project, so if I'm making an effort to remove something, there's a good reason why, and people should just stop second guessing me. "It's just not needed" is a great reason to remove things if possible in this project. In a later, non embedded, not needing to be approved by the government, not having to run on a x486, project I plan on doing, and another one I started in January, there will be need for all the bells and whistles. In this project, and the next embedded project, it's really important to cut the bloat. Remember, one of the important things we claim for EFL is it's small size and usefulness on embedded systems. I'm reality checking those claims in some of my work. I need to get it to work on a tiny little x486. Personally I would have preferred a somewhat more grunty ARM, on an even smaller board, but I could not convince the client of that. The x486 board had one thing on it that could not be found on any ARM board, at a reasonable cost, an interface to some other part of the hardware of the completed system. Oh well, at least I like this sort of challange. B-) So next time I say "Hey, X is not working well when you disable Y, but it should", please, I don't want people telling me over and over again "Just leave Y in, it's all good, you'll need it". Coz at that stage, I've already decided that I'm better off without it, with damn good reasons. </rant> <sleep> ... -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
