Re: [Denemo-devel] The 1.0 release

[Richard Shann]

> 
> I have the .a separated because I wanted to have additional CFLAGS for 
> these files only.
> -lportmidi would require a .so or dynamically linking. We are not doing 
> that because portmidi uses cmake instead of autotools. Gub has no 
> support for cmake. I don't know how I would do it. I don't know anything 
> about cmake. I tried reading through all the files and I hope I am 
> compiling all the necessary files for the respected platform with the 
> correct compiler and linker flags but I really don't know. The main 
> problem is that I don't know what I am doing here. Using -lportmidi 
> would be the most ideal but I would have to find time to learn cmake 
> more and figure out how to hack this into gub. Since while composing 
> this email I probably have been interrupted about 20 times, I don't 
> think the possibility of me learning something new will happen any time 
> soon.
It sounds like you made the right decision not to try and use cmake.
Having got the .o files for portmidi I guess they could have just gone
on to the link line, but I am guessing that putting them into a library
and putting that on the link line works as well, otherwise the other
libraries (sffile etc) that you have done that way would not have
worked. I am very confused about the different ways that the sources are
mentioned 
I see in denemo.py

class Denemo (target.AutoBuild):
    source = 'git://git.savannah.gnu.org/denemo.git'

and later

class Denemo__mingw__windows (Denemo):
 source = 'git://git.savannah.gnu.org/denemo.git'
 branch = 'mingw'

while denemo.make has

DENEMO_BRANCH="master"
DENEMO_REPO_URL=git://git.savannah.gnu.org/denemo.git

Should that last one be "mingw" if I am building for windows?

Oh - and please don't feel pressured to reply quickly, though I am sure
you would love to see all this stuff working at last, I know what kids
are like...

Richard