Re: Win32 Zinf with MingW

"David Hough" <[email protected]> Wed, 27 Apr 2005 07:36:37 -0500
Newsgroups gmane.comp.audio.zinf.devel
Message-ID <[email protected]>
On 26/4/2005, "kristian kvilekval" <[email protected]> wrote:
...
>> OK, I've sort of got the unix build working again. I haven't fixed the
>> libzinf/io dir problem though, so to build on both linux and win32 you
>> would have to execute
>> make; cd base; make; cd ..; make
>
>We should see if there is way to make a library of functionality
>so that we can link with the DLLs
>without missing symbols.  We could also see about using
>the message system to communicate between the co-dependent
>parts.

I would prefer to find a solution to this that didn't requrie modifing
any source code, if at all possible. It really comes down to a basic
build ordering problem. At the moment I can think of 3 possible fixes,
none of which are particular great, and all of which require changing
the directory build order from "io base" to "base io"

1) Move io/src/*.cpp  to  base/src/*.cpp
Problem - Requires reorganisation, and also means not all IO specific
source code is stored in the IO subdirectory any more.

2) Instead of building the convience library io/libio.la, we add the
files in io/src to the list of sources of libzinf in base/Makefile.am
Problem - Breaks the logical link between the location of a source file
and the location of it's makefile, so could make maintaince more
difficult.

3) Force base/Makefile.am to build io/libio.la before building libzinf
using something like:
make -C ../io libio.la
Problem - Not sure we can actually do this with AutoMake without using
some non-portable hacks in the makefiles, also makes the build ordering
much less obvious.

(Note: I haven't actually tried to do any of these)

Option 1 seems the cleanist solution if you ignore CVS, but if 3 is
actually simple to do I suspect that may our best option as it means the
least changes to how things currently work.

...

>> > Which is kind of a no-no with CVS; how about dumping CVS and switching
>> > to Arch completly?
>>
>> One slight problem that I feel I should point out, what with the attempt
>> to get win32 support back and all, is that there is no offical
>> implementation of Arch on Windows, and not much hope of one soon.
>>

...

>I had thought of using mingw32 on unix system to cross-compile
>win32 apps.  I wasn't expecting to develop on win32 using cygwin or
>msys.   Have you tried this?

I haven't tried cross-compiling, I've purely been using MSys/MingW to
compile Zinf on Windows. Cross-compiling sounds fine for most
development but working on the Windows specific code really needs to be
done in Windows.

Though as I've been dual-booting between linux and windows, I've just
been getting the code from Arch in linux and rebooting, so I have to
admit that I haven't actually been using CVS for this. I do think,
however, removing CVS would be a serious barrier to doing much
development on the Windows port in future. It seems rather stupid to say
you need tools that only run on linux to do any development work in
windows.

Now it may be the case that Arch on windows is "good enough" for use
with Zinf (I haven't tried it in a while), in which case this argument
is null and void. However, we should bear in mind that Arch is probably
more of a hinderance to Windows development then a help.

Cheers,
David


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix