1 Mar
2004
1 Mar
'04
10:46 p.m.
I'm quite a fan of alsamodularsynth and have been recommending it to
friends. The only problem I have with it is that rather than use
automake/autoconf for building it has Makefiles that only work without
editing under SuSE. Of course, editing the Makefiles to get it to build
on other distributions and installing the required development packages
is trivial.
But I was hoping I could save other people the work of having to do this
by writing autoconf/automake scripts. The reason I'm writing this to the
list is to ask whether anyone else has already done this and can save me
the trouble. I know alsamodularsynth has been packaged for other
distributions, and I also know that it's being packaged for Debian
(although that's been going on for a very long time, so I assume it's
now stalled).
One would have thought that had this work already been done, the result
would have made it into the tarball on sourceforge. But stranger things
have happened.
--
Mark
1 Mar
1 Mar
11:40 p.m.
On Mon, 2004-03-01 at 22:41, Mark Johnathan Greenaway wrote:
I'm quite a fan of alsamodularsynth and have been
recommending it to
friends. The only problem I have with it is that rather than use
automake/autoconf for building it has Makefiles that only work without
editing under SuSE. Of course, editing the Makefiles to get it to build
on other distributions and installing the required development packages
is trivial.
But I was hoping I could save other people the work of having to do this
by writing autoconf/automake scripts. The reason I'm writing this to the
list is to ask whether anyone else has already done this and can save me
the trouble. I know alsamodularsynth has been packaged for other
distributions, and I also know that it's being packaged for Debian
(although that's been going on for a very long time, so I assume it's
now stalled).
One would have thought that had this work already been done, the result
would have made it into the tarball on sourceforge. But stranger things
have happened.
I can do it if you want. It won't take more than 10 minutes really.
For all I complain about AMS on this list I guess I should contribute
/something/. :)
-Dave
11:58 p.m.
On Mon, Mar 01, 2004 at 11:36:42PM -0500, Dave Robillard wrote:
That'd be cool. I can think of at least two people who will appreciate
it :)
--
Mark
I'm quite
a fan of alsamodularsynth and have been recommending it to
friends. The only problem I have with it is that rather than use
automake/autoconf for building it has Makefiles that only work without
editing under SuSE. Of course, editing the Makefiles to get it to build
on other distributions and installing the required development packages
is trivial.
But I was hoping I could save other people the work of having to do this
by writing autoconf/automake scripts. The reason I'm writing this to the
list is to ask whether anyone else has already done this and can save me
the trouble. I know alsamodularsynth has been packaged for other
distributions, and I also know that it's being packaged for Debian
(although that's been going on for a very long time, so I assume it's
now stalled).
One would have thought that had this work already been done, the result
would have made it into the tarball on sourceforge. But stranger things
have happened.
I can do it if you want. It won't take more than 10 minutes
really.
For all I complain about AMS on this list I guess I should contribute
/something/. :)
2 Mar
2 Mar
12:30 a.m.
On Mon, 2004-03-01 at 23:53, Mark Johnathan Greenaway wrote:
On Mon, Mar 01, 2004 at 11:36:42PM -0500, Dave
Robillard wrote:
That'd be cool. I can think of at least two people who will appreciate
it :)
Alright, I'll do it this week. Probably wednesday, but no guarantees.
Midterms and all...
-Dave
I'm
quite a fan of alsamodularsynth and have been recommending it to
friends. The only problem I have with it is that rather than use
automake/autoconf for building it has Makefiles that only work without
editing under SuSE. Of course, editing the Makefiles to get it to build
on other distributions and installing the required development packages
is trivial.
But I was hoping I could save other people the work of having to do this
by writing autoconf/automake scripts. The reason I'm writing this to the
list is to ask whether anyone else has already done this and can save me
the trouble. I know alsamodularsynth has been packaged for other
distributions, and I also know that it's being packaged for Debian
(although that's been going on for a very long time, so I assume it's
now stalled).
One would have thought that had this work already been done, the result
would have made it into the tarball on sourceforge. But stranger things
have happened.
I can do it if you want. It won't take more than 10 minutes
really.
For all I complain about AMS on this list I guess I should contribute
/something/. :) 
6:11 a.m.
On Tue, 2 Mar 2004, Dave Robillard wrote:
On Mon, 2004-03-01 at 23:53, Mark Johnathan Greenaway
wrote:
> On Mon, Mar 01, 2004 at 11:36:42PM -0500, Dave Robillard wrote:
> > > I'm quite a fan of alsamodularsynth and have been recommending it to
> > > friends. The only problem I have with it is that rather than use
> > > automake/autoconf for building it has Makefiles that only work without
> > > editing under SuSE. Of course, editing the Makefiles to get it to build
> > > on other distributions and installing the required development packages
> > > is trivial.
You only have to edit the library path constants at the beginning of
the Makefile. If you have adapted that to the requirements of your system
once, you can just copy and paste it in any new Makefile of any new ams
release. It's indeed trivial. I don't like the idea of automake/autoconf.
I've got the impression that these pose more problems than they are
actually solving. So unless somebody convinces me, I won't include this
mechanism into the official ams tarball.
Alright, I'll do it this week. Probably
wednesday, but no guarantees.
Midterms and all...
Maybe it's a good idea to wait until ams-1.7.6. ams-1.7.5 is an
intermediate release which has a bug in the new sustain/hold pedal
feature. I plan to release ams-1.7.6 this week, maybe even tonight.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
6:35 a.m.
On Tue, Mar 02, 2004 at 11:46:59AM +0100, Matthias Nagorni wrote:
On Tue, 2 Mar 2004, Dave Robillard wrote:
I agree. Automake/autoconf are fine if you want real cross-platform portability,
but introducing this will not be done in 10 minutes as it will require changes to
most if not all source files as well, in order to use all the #defines created
by the system. And the changes required for compilation on other Linux distros
should be trivial indeed (iff all the required packages are already installed).
--
Fons
On Mon, 2004-03-01 at 23:53, Mark Johnathan
Greenaway wrote:
> On Mon, Mar 01, 2004 at 11:36:42PM -0500, Dave Robillard wrote:
> > > I'm quite a fan of alsamodularsynth and have been recommending it to
> > > friends. The only problem I have with it is that rather than use
> > > automake/autoconf for building it has Makefiles that only work without
> > > editing under SuSE. Of course, editing the Makefiles to get it to build
> > > on other distributions and installing the required development packages
> > > is trivial.
You only have to edit the library path constants at the beginning of
the Makefile. If you have adapted that to the requirements of your system
once, you can just copy and paste it in any new Makefile of any new ams
release. It's indeed trivial. I don't like the idea of automake/autoconf.
I've got the impression that these pose more problems than they are
actually solving. So unless somebody convinces me, I won't include this
mechanism into the official ams tarball.
8:32 a.m.
On Tue, 2004-03-02 at 05:46, Matthias Nagorni wrote:
On Tue, 2 Mar 2004, Dave Robillard wrote:
Fair enough. ./configure etc. is without a doubt THE way to distribute
free software though. Most people find it quite annoying when an app
doesn't follow the 'standard'.
Users simply don't like hand-editing and copying configuration files
around. At the very simplest level I don't want to edit the Makefile to
make AMS use my preferred CFLAGS, and know where to find QT, and install
to /usr. I just want to "./configure --prefix=/usr" and be done with it.
-Dave
On Mon, 2004-03-01 at 23:53, Mark Johnathan
Greenaway wrote:
> On Mon, Mar 01, 2004 at 11:36:42PM -0500, Dave Robillard wrote:
> > > I'm quite a fan of alsamodularsynth and have been recommending it to
> > > friends. The only problem I have with it is that rather than use
> > > automake/autoconf for building it has Makefiles that only work without
> > > editing under SuSE. Of course, editing the Makefiles to get it to build
> > > on other distributions and installing the required development packages
> > > is trivial.
You only have to edit the library path constants at the beginning of
the Makefile. If you have adapted that to the requirements of your system
once, you can just copy and paste it in any new Makefile of any new ams
release. It's indeed trivial. I don't like the idea of automake/autoconf.
I've got the impression that these pose more problems than they are
actually solving. So unless somebody convinces me, I won't include this
mechanism into the official ams tarball.
8:42 a.m.
On Tue, Mar 02, 2004 at 08:28:12AM -0500, Dave Robillard wrote:
Fair enough. ./configure etc. is without a doubt THE
way to distribute
free software though. Most people find it quite annoying when an app
doesn't follow the 'standard'.
Users simply don't like hand-editing and copying configuration files
around. At the very simplest level I don't want to edit the Makefile to
make AMS use my preferred CFLAGS, and know where to find QT, and install
to /usr. I just want to "./configure --prefix=/usr" and be done with it.
On of the reasons I try to avoid automake/autoconf is that when for some
reason it doesn't work on your system, you're lost unless you are an
expert with those tools, and they are not the easiest ones. A cleanly
written Makefile is a lot easier to fix in that case, and requires less
expert knowledge.
--
Fons
9:07 a.m.
On Tue, 2004-03-02 at 08:37, Alfons Adriaensen wrote:
On Tue, Mar 02, 2004 at 08:28:12AM -0500, Dave
Robillard wrote:
The input files to a proper autotools-ized project are quite a bit
smaller and cleaner than a 400 line Makefile..
I agree it may be a bit more of a hassle to set things up than just
writing a Makefile (if you already just know make that is), but I tend
to look at things from a user perspective, and ./configure is just
simpler. Don't have to do something special for every damn app out
there..
-Dave
Fair enough. ./configure etc. is without a doubt
THE way to distribute
free software though. Most people find it quite annoying when an app
doesn't follow the 'standard'.
Users simply don't like hand-editing and copying configuration files
around. At the very simplest level I don't want to edit the Makefile to
make AMS use my preferred CFLAGS, and know where to find QT, and install
to /usr. I just want to "./configure --prefix=/usr" and be done with it.
On of the reasons I try to avoid automake/autoconf is that when for some
reason it doesn't work on your system, you're lost unless you are an
expert with those tools, and they are not the easiest ones. A cleanly
written Makefile is a lot easier to fix in that case, and requires less
expert knowledge. 
6:48 p.m.
On Tuesday 02 March 2004 15:03, Dave Robillard wrote:
On Tue, 2004-03-02 at 08:37, Alfons Adriaensen wrote:
If you like, you can create an autotool project graphically using
kdevelop-3.0. It comes with an "automake manager". With a little knowledge of
the backgrounds you can easily setup a project (even including subprojects).
The targets can be configured to be apps, static or dynamic libs (lib or
libtool), etc. The installation can be handled too. There is more stuff to
control, but i'm not that into it.
I don't say you should use kdevelop for coding, just create the autotool stuff
once and you have a good start.
It tried autotools without kdevelop before. It was a pain. Cut-and paste,
loops of iterations and still not fully understood it. The graphical
interface helps here.
I packaged lindrum(to be renamed) with kdevelop recently. It creates two
static and one dynamic lib and an app. To integrate the Qt stuff i used a
trick from the author of qjackctl . His package uses qmake internally but
offers an autoconf setup.
PE
--
"Without music, life would _O_/ \_O_/ +----------------------+
be a mistake - I would / )) [] | Peter Eschler |
only believe in a god who \\ // | peschler(a)t-online.de |
knew how to dance." (Nietzsche) // \\ +----------------------+
On of the reasons I try to avoid
automake/autoconf is that when for some
reason it doesn't work on your system, you're lost unless you are an
expert with those tools, and they are not the easiest ones. A cleanly
written Makefile is a lot easier to fix in that case, and requires less
expert knowledge.
The input files to a proper autotools-ized project are quite a bit
smaller and cleaner than a 400 line Makefile..
I agree it may be a bit more of a hassle to set things up than just
writing a Makefile (if you already just know make that is), but I tend
to look at things from a user perspective, and ./configure is just
simpler. Don't have to do something special for every damn app out
there..
7366
days inactive
7367
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Dave Robillard -
Mark Johnathan Greenaway -
Matthias Nagorni -
peschler＠t-online.de