I'm not going to try to apply and test these tonight; it's too late for me for that kind of stuff. Comments I can do though..
> There's a typo in an assert() in rtree.c. The fix is to compare Y with > Y, not X, in the last >: OK. > The batch HID won't even build, because it's missing file watch and > block hook functions, and its progress function return type is wrong. I use it for the web server, so it doesn't get rebuilt often. I'll look into it unless Dan beats me to it. > (I found this before discovering I don't want to build it because it > claims to be a GUI HID, even though there's nothing G about its UI, and > thus, depending on order in the list in hidlist.h, likes to preempt my > GUI HID.) Well, "gui" in this case means "the primary interface with the user" as opposed to, for example, export/import/printing HIDs. I'm surprised the configury let you select it. I don't think it's supposed to allow more than one gui hid, although it would be cool if you could select them at runtime. > autoroute.c has an assert() referring to "region", which is not > declared anywhere I could find: Unusual. I guess we don't test with assertions enabled. > There are some more things which aren't really bugs, but are things I > had to change, because the compiler I'm using didn't like them. Which compiler? > Several places have object declarations following executable code. That's bad and should be fixed. > macro.h uses an unrecognized #pragma. If this is doing what it looks > like, it could perhaps be more portably done by #defining them to > something that will produce a syntax error. It's not quite the same. Poisoning only affects uses of the token in the source, not uses of the token as the expansion of a previous macro definition. But the #if should have kept it out, perhaps we need to test gcc's version number too. > I ripped out hid_load_dir() in hid/common/hidinit.c because it would > prevent me from linking static; Yeah, that change isn't useful in general unless you can come up with a ./configure option for it. > I ripped out the calls to bindtextdomain and bind_textdomain_codeset > in main.c because I couldn't find them anywhere (presumably they > come from some facility "everyone" has but I don't); libintl. You can get it from the FSF's gettext package. A patch to test for it in configure and conditionalize it would be OK though. > and I changed the varargs DEBUGP macros in polygon1.c to match my > compiler's varargs macro syntax. Probably needs to be conditionaled on a gcc version check. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
