Re: [bug-mes] Simple division algorithm

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

>> We need it to be available in any program compiled by mescc that
>> contains an "/" or "%" operator, without the user #including
>> anything.
>> 
>> I've committed a new file lib/mes/div.c to origin/wip+wip-arm and
>> also modified lib/mes/ntoab.c to be the first explicit user (that's
>> not so nice--but I keep it for now as a place where I can see it).

OK.

> Could you make it that it will be linked in programs compiled by mescc
> and not linked-in otherwise?  I'm not sure how to do that.
>
> If it's not possible, we can always link it in--it won't be called in
> the case of gcc anyway.
>
> But it would be clearer if mes builtins were not present in
> gcc-compiled things.

Ah, so what we'd want is some kind of mescc-special library that
is always linked against.

There currently is not such a library or distinction... mescc uses -lc
(mes libc) by default.  It can also link without C library or with
libc-mini, libc+tcc, libc+gnu.

For now, I included it for mescc builds in mes libc

--8<---------------cut here---------------start------------->8---
diff --git a/lib/libmes.c b/lib/libmes.c
index 528d1c45..e0ec54ba 100644
--- a/lib/libmes.c
+++ b/lib/libmes.c
@@ -74,3 +74,7 @@ mes_open (char const *file_name, int flags, int mask)
 
 #include <mes/eputc.c>
 #include <mes/oputc.c>
+
+#if __MESC__
+#include "mes/div.c"
+#endif
--8<---------------cut here---------------end--------------->8---

... it gets included in mescc builds of mes/libc (and the larger
libraries libc+tcc, libc+gnu).

I would like to get the configure+build simplified before adding more
features, but I don't have a plan for how to do that yet.

Together with Jeremiah Orians we made a pretty nice and simplistic build
for mes-m2.  I'm trying to steal ideas from that and we have already
removed the build time snarfing of C sources in on the WIP branches.

The mes-m2 build is conveniently ignoring mescc builds, building of
various flavours of mes c library (simply uses gcc+glibc for now),
multiple architectures/cross compiling as well as GNU build system
compliance that we'll want (and need as a GNU package).

I'm convinced we can have both a much simpler build while being (mostly)
standard complient but that needs more thought (and some work).

Greetings,
janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com