| Your point about libary compatibility for precompiled packages is in principle correct. This is a well-known problem and the Linux community is working to address it with ABI standards. Nevertheless the problem is not going away very soon.
However, this is all somewhat theoretical. What are people's actual experiences with installing Csound 5 with precompiled C++ on different versions of Linux? I'm not talking about CsoundVST here, but about widgets.cpp, fluidOpcodes, and cs4vst.
Of course, I am always running csound 5 on the system that compiled it. On Linux and Unix, I think it is considered acceptable to distribute a package in the form of source code and expect the user to compile it, which resolves this problem.
However, I don't mean to minimize the problem. Users increasingly expect precompiled packages, and especially for musicians this would be a big plus.
I initially opposed having the FLTK widgets in the Csound distribution, but I changed my mind because so many people seemed to find them useful or even essential. I would not oppose their removal if the Csound 5 community mostly agreed to remove them.
My points about bugs and speed are separate issues.
-----Original Message-----
From: vanDongen/Gilcher
Sent: Mar 24, 2005 5:53 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Broken again
On Tuesday 22 March 2005 15:27, Michael Gogins wrote:
> In my view, Csound would contain fewer bugs and run slightly faster if it
> were coded entirely in C++. This view is based on experience and
> experiments, not opinion. I am prepared to show code samples and
> experimental results to support this view. I would of course be very
> interested to review code samples and experimental results that demonstrate
> the opposite.
>
My experience is not very extensive, so please correct me if I am wrong.
The biggest problem I have seen with C++ is binary incompatability between
libraries and applications using them. This is actually not that much of a
problem for me, just the nuisance that upgrading the compiler means
recompiling all my C++ libraries. And I don't upgrade my compiler that
often :)
But for distributing binaries of programs using a shared libcsound it is a
real problem. The program won't run if it was compiled for a libcsound
compiled differently. Even a different optimization flag will break binary
compatibility I think. The only solution is to distribute a statically linked
private copy of libcsound with your application.
So I think that the ambition of csound5 as a platform independent library is
best served by it being pure C.
(And yes, I think including widgets in core Csound5 was/is a mistake. For one
thing it assumes that csound will only be run on general purpose pc's, and
that as long as you support windows, Mac and linux you are cross platform. My
cell phone has a 400 MHz processor and stereo sound. Csound should run on
that, and it will but without the widgets. Including C++ and widgets in the
core csound, will just create a forks for other uses. )
Gerard
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |