[EMAIL PROTECTED] wrote:
*) If I understand you you correctly and you like to see a tool that is able
to
do this with any unknown random feature. You would always hand code tests
for
some of the OS features.
Well, in some way. But you could have a library with a lot of common
features
[EMAIL PROTECTED] wrote:
*) If I understand you you correctly and you like to see a tool that is able to
do this with any unknown random feature. You would always hand code tests for
some of the OS features.
Well, in some way. But you could have a library with a lot of common
features and
Bart Smaalders [EMAIL PROTECTED] wrote:
So what is needed is a tool that examines a working program
and it's libraries, and produces a configure script. It would
flag functions that have no configure support or that are known
not to be portable.
This could probably be done by using calltree
UNIX admin [EMAIL PROTECTED] wrote:
You'll need to add something like the following to
configure.in:
AC_CHECK_FUNC(sched_get_priority_max, [true],
[AC_CHECK_LIB(rt, sched_get_priority_max)])
Can't we just kill configure and put whoever invented it in jail with a
criminal
confugire itself is not bad.
Bad is the current GNU variant of the tool that requires
bash to be available in order to work.
Bad is the fact that most projects miss-use confifure to create
Makefiles instead of just letting it test the compile environment
and create an include file that contains
[EMAIL PROTECTED] wrote:
confugire itself is not bad.
Bad is the current GNU variant of the tool that requires
bash to be available in order to work.
Bad is the fact that most projects miss-use confifure to create
Makefiles instead of just letting it test the compile environment
and
*) If I understand you you correctly and you like to see a tool that is able to
do this with any unknown random feature. You would always hand code tests for
some of the OS features.
Well, in some way. But you could have a library with a lot of common
features and symbols.
People also do not
You'll need to add something like the following to
configure.in:
AC_CHECK_FUNC(sched_get_priority_max, [true],
[AC_CHECK_LIB(rt, sched_get_priority_max)])
Can't we just kill configure and put whoever invented it in jail with a
criminal conviction?
This message posted from
There is no Solaris driver for Jack anyway. Yet. ;-)
Apparently so.
And Jack is really not crappy at all. The design is
actually quite
clean and elegant. it is based on operating system
specific loadable
modules.
That's an oximoron: how can the design be clean if it is based on operating
This is still higher quality software than Gnome that
reads /proc/scsi
or similar spread over the source. Readon /proc/scsi
will probably never be
detected. The related function just don't work for
some strange reason.
If it's any comfort to you, I for my part wish there were more Joerg
On 5/20/06, UNIX admin [EMAIL PROTECTED] wrote:
There is no Solaris driver for Jack anyway. Yet. ;-)
Apparently so.
Not apparently so, definitely so.
And Jack is really not crappy at all. The design is
actually quite
clean and elegant. it is based on operating system
specific loadable
Hi Stefan,
I'm happy to read from you in this forum.
As i explained a few monthes ago in your kde-solaris forum, old versions from
the new Rosegarden have really full worked with old versions of aRTs, i mean
only two or three years ago.
I tried this at the summer 2005 with actuals versions of
On 5/15/06, Serge [EMAIL PROTECTED] wrote:
Hi Stefan,
I'm happy to read from you in this forum.
Hi. :-)
As i explained a few monthes ago in your kde-solaris forum, old versions from
the new
Rosegarden have really full worked with old versions of aRTs, i mean only two
or three
years ago.
Le lundi 15 mai 2006 15:36 -0400, Stefan Teleman a crit :
i'm working on a native Solaris driver for Jack. which will remove the
need for aRts, and Rosegarden has builtin support for Jack audio.
and midi, i presume : we compose in midi mode, and Rosegarden need a midi device
14 matches
Mail list logo
