Re: [UCI-Devel] Problems compiling libuci on VC6++

First off, sorry for my lateness in replying to this.. as I posted to the UCI
list a couple of days ago, my mail server had a hard disk crash which took me
several days to recover from, and I haven't had much time to wade through my
back mail this week, so I'm running rather behind on things..

Please don't let my late reply be misconstrued as lack of interest, though.  I
am very interested in the possibility of using UCI in Vdub, and in windows in
general, and am eager to help anybody interested in working on such things.

On Fri, Nov 15, 2002 at 08:17:25AM +0100, ChristianHJW wrote:
> http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&t
> =168&start=15
> 
> Suiryc wrote :
> 
> [quote]
> I had a look at UCI CVS and some changes will have to be made for the code
> being useable under VC++ 6 (and other compilers I think).

Cool!  I'm very interested in any feedback regarding this sort of thing (since
I don't have any VC++ development stuff to work with myself)

> According to the problems I encountered and what I could find on the net
> seems like foogod uses GCC to compile (or similar) because there are some
> features that cannot be used in VC++ 6 (even maybe under VC++.NET, didn't
> tested).

Yeah, the current libuci code was written for gcc under linux, because that's
my primary development environment.  I tried to make things fairly standard and
portable (and the bits which weren't portable I isolated in platform-specific
portions of the code (platform_linux.c)), but I guess I didn't do as well as
I'd hoped.  I'm open to submissions of code changes to make it more compatible
with other environments, though.  Any info you can provide in this regard is
welcome.

> What I am talking about here concerns the uci_param_value union, and the
> macros defined to initialize / generate constants out of it.
> foogod uses a {.field = value} trick that, as far as I could read, is
> defined in C99 specs (standard C specs). But apparently there is not that
> much compiler that are C99 compliant (they are just C89 compliant) : even
> GCC (that can handle the trick thought) isn't 100% C99 compliant.

Humph.. here I specifically used that because I'd seen on other lists that it
worked better than the alternative (gnu-style) "field: value" syntax for some
compilers (I'd thought including MSVC++, but apparently not).

So do I take it that there is no way to do static initializers for unions in
VC++ at all?  That would be a problem.

> A workaround is to define constructors for the union ... but of course in
> this case we are not anymore in C but C++ ... (which makes me have to force
> casts  ).

Sigh.. yeah.. I suppose it's possible we could use C++-isms for VC++, but I'd
like to avoid that sort of thing if possible.  I suppose I could just rewrite
the union initializers as casts, which should work, and doesn't require C++,
but is an ugly hack and could theoretically produce some broken results if a C
implementation does unions in unusual ways.  Alternately, it might be worth
giving up on the idea of unions altogether, as has been suggested for other
reasons.  I'll put some thought into this and see what comes out..

> And then I learn that VC++ isn't POSIX, which makes that the
> platform_linux.c has to be reworked too (half of the functions and
> structures used are not defined in VC++).

Yeah, that's why they were in platform_linux.c..  Those are all the routines
which I figured were likely to require differing implementations for different
platforms, so I designed things in such a way that libuci can have a
platform_linux.c, platform_win32.c, etc, and then the appropriate file can be
compiled/linked in depending on which platform you're building for.

> Finally after a *lot* of hack I could use the files ...[/quote]

I'd be very interested in seeing the changes you had to make to make things
compile in VC++.  If you'd be willing to send them to me, I can try to
integrate them back into the main libuci code so that it'll work better in
future.

-alex


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf