MusE - Linux Music Editor

On 07/30/12 05:56, Robert Jonsson wrote:
> MusE 2.0.1 July 29, 2012
>
> This is a bug fix release that mainly fixes a problem with moving
> plugins in the plugin rack.
>
> Some changes:
> - Fixed controllers go wacky after moving effects rack plugins up/down.
> - Changed naming convention for recorded wave files to include track
> name and it's take number
> - Use cmake's own FindPythonLibs module instead of pkgconfig to detect Python
> - Updated Czech translation from Pavel Fric
> - Increased zoom range a bit in arranger
>
well done Robert ! At this rate MusE will look to the world like a 
living active project ;-)

good news.

g

Hi Andy,

2012/7/6  <adr-muse@...>:
>
> Hi,
> when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
> installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
> has Python 2.6 installed.
>
> 'cmake -L ..' tells me:
> -- checking for module 'python>=2.4'
> --   package 'python>=2.4' not found
> [...]
> The following components WILL NOT be built:
> -----------------------------------------------
>    Python support
>    Experimental features

That was odd. Must be a bug in the detection. Where is python2.6
installed on centos and what is the binary called?

Regards,
Robert

> I tried to build with -DENABLE_PYTHON=1 but I still get the above
> output.
>
> How can I convince muse/cmake that I have python >= 2.4 installed?
>
> Thanks,
> Andy
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user

On Fri, 6 Jul 2012, Robert Jonsson wrote:

> Hi Andy,
> 
> 2012/7/6  <adr-muse@...>:
> >
> > Hi,
> > when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
> > installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
> > has Python 2.6 installed.
> >
> > 'cmake -L ..' tells me:
> > -- checking for module 'python>=2.4'
> > --   package 'python>=2.4' not found
> > [...]
> > The following components WILL NOT be built:
> > -----------------------------------------------
> >    Python support
> >    Experimental features
> 
> That was odd. Must be a bug in the detection. Where is python2.6
> installed on centos and what is the binary called?

Python is installed in the usual locations, specifically:
/usr/bin/python
/usr/bin/python2.6

I think the reason is that Muse is doing a PKG_CHECK_MODULES check for 
python but python (at least python 2.6) doesn't have a pkgconfig (.pc) 
file!
The python devel package includes a 'python-config' binary in /usr/bin 
which is used instead of the pkgconfig (.pc) file so a cmake 
PKG_CHECK_MODULES will fail.

Isn't this the same on other distros?

Does the python check work on any distro?

Thanks,
Andy

2012/7/6  <adr-muse@...>:
> On Fri, 6 Jul 2012, Robert Jonsson wrote:
>
>> Hi Andy,
>>
>> 2012/7/6  <adr-muse@...>:
>> >
>> > Hi,
>> > when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
>> > installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
>> > has Python 2.6 installed.
>> >
>> > 'cmake -L ..' tells me:
>> > -- checking for module 'python>=2.4'
>> > --   package 'python>=2.4' not found
>> > [...]
>> > The following components WILL NOT be built:
>> > -----------------------------------------------
>> >    Python support
>> >    Experimental features
>>
>> That was odd. Must be a bug in the detection. Where is python2.6
>> installed on centos and what is the binary called?
>
> Python is installed in the usual locations, specifically:
> /usr/bin/python
> /usr/bin/python2.6
>
> I think the reason is that Muse is doing a PKG_CHECK_MODULES check for
> python but python (at least python 2.6) doesn't have a pkgconfig (.pc)
> file!
> The python devel package includes a 'python-config' binary in /usr/bin
> which is used instead of the pkgconfig (.pc) file so a cmake
> PKG_CHECK_MODULES will fail.
>
> Isn't this the same on other distros?
>
> Does the python check work on any distro?

You could be right, atleast partially. It was a while since we
compiled explicitly with python support so it is possible it does not
work, but your error does not happen here.
Is the configuration not completed so you could run make anyway?

For this particular machine My NOT to build list includes:
The following components WILL NOT be built:
-----------------------------------------------
   Lash support
   Python support
   Experimental features

With kubuntu here it actually does have a python2.pc, no time to check
now if that is used.

Regards,
Robert

On Fri, 6 Jul 2012, Robert Jonsson wrote:

> 2012/7/6  <adr-muse@...>:
> > On Fri, 6 Jul 2012, Robert Jonsson wrote:
> >
> >> Hi Andy,
> >>
> >> 2012/7/6  <adr-muse@...>:
> >> >
> >> > Hi,
> >> > when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
> >> > installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
> >> > has Python 2.6 installed.
> >> >
> >> > 'cmake -L ..' tells me:
> >> > -- checking for module 'python>=2.4'
> >> > --   package 'python>=2.4' not found
> >> > [...]
> >> > The following components WILL NOT be built:
> >> > -----------------------------------------------
> >> >    Python support
> >> >    Experimental features
> >>
> >> That was odd. Must be a bug in the detection. Where is python2.6
> >> installed on centos and what is the binary called?
> >
> > Python is installed in the usual locations, specifically:
> > /usr/bin/python
> > /usr/bin/python2.6
> >
> > I think the reason is that Muse is doing a PKG_CHECK_MODULES check for
> > python but python (at least python 2.6) doesn't have a pkgconfig (.pc)
> > file!
> > The python devel package includes a 'python-config' binary in /usr/bin
> > which is used instead of the pkgconfig (.pc) file so a cmake
> > PKG_CHECK_MODULES will fail.
> >
> > Isn't this the same on other distros?
> >
> > Does the python check work on any distro?
> 
> You could be right, atleast partially. It was a while since we
> compiled explicitly with python support so it is possible it does not
> work, but your error does not happen here.

Have you tried running cmake with -DENABLE_PYTHON=1 ?
If not, then cmake won't even check for python.


> Is the configuration not completed so you could run make anyway?

Yes the configuration completes and I can run make and build Muse, but I 
would like to build it with Python support as this is for a Centos 
package for my Centos packages repo (http://pkgrepo.linuxtech.net/el6/)
which is used by quite a few people, so I like to build the packages 
with as much functionality enabled as possible.

 
> For this particular machine My NOT to build list includes:
> The following components WILL NOT be built:
> -----------------------------------------------
>    Lash support
>    Python support
>    Experimental features
> 
> With kubuntu here it actually does have a python2.pc, no time to check
> now if that is used.

Correct me if I'm wrong (I know next to nothing about cmake) but 
PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like 
'pkg-config --modversion python' and then checks that the version 
returned is >= 2.4.

On your kubuntu this shouldn't fail (unless the fact that the .pc file 
is called python2 rather than python confuses cmake) but on Centos or 
Fedora it will always fail given the lack of a .pc file.

I think the cmake python check needs to be rewritten to work everywhere. 

As I said I have no experience with cmake so unfortunately I can't 
provide you with a patch for this but it would be great if someone with 
cmake experience could look at it.

Regards,
Andy

Hi,

2012/7/6  <adr-muse@...>:
> On Fri, 6 Jul 2012, Robert Jonsson wrote:
>
>> 2012/7/6  <adr-muse@...>:
>> > On Fri, 6 Jul 2012, Robert Jonsson wrote:
>> >
>> >> Hi Andy,
>> >>
>> >> 2012/7/6  <adr-muse@...>:
>> >> >
>> >> > Hi,
>> >> > when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
>> >> > installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
>> >> > has Python 2.6 installed.
>> >> >
>> >> > 'cmake -L ..' tells me:
>> >> > -- checking for module 'python>=2.4'
>> >> > --   package 'python>=2.4' not found
>> >> > [...]
>> >> > The following components WILL NOT be built:
>> >> > -----------------------------------------------
>> >> >    Python support
>> >> >    Experimental features
>> >>
>> >> That was odd. Must be a bug in the detection. Where is python2.6
>> >> installed on centos and what is the binary called?
>> >
>> > Python is installed in the usual locations, specifically:
>> > /usr/bin/python
>> > /usr/bin/python2.6
>> >
>> > I think the reason is that Muse is doing a PKG_CHECK_MODULES check for
>> > python but python (at least python 2.6) doesn't have a pkgconfig (.pc)
>> > file!
>> > The python devel package includes a 'python-config' binary in /usr/bin
>> > which is used instead of the pkgconfig (.pc) file so a cmake
>> > PKG_CHECK_MODULES will fail.
>> >
>> > Isn't this the same on other distros?
>> >
>> > Does the python check work on any distro?
>>
>> You could be right, atleast partially. It was a while since we
>> compiled explicitly with python support so it is possible it does not
>> work, but your error does not happen here.
>
> Have you tried running cmake with -DENABLE_PYTHON=1 ?
> If not, then cmake won't even check for python.
>
>
>> Is the configuration not completed so you could run make anyway?
>
> Yes the configuration completes and I can run make and build Muse, but I
> would like to build it with Python support as this is for a Centos
> package for my Centos packages repo (http://pkgrepo.linuxtech.net/el6/)
> which is used by quite a few people, so I like to build the packages
> with as much functionality enabled as possible.
>

I see, in that case you safely skip the python support, it is part of
the experimental stuff and does not add anything usable in it's
current state.

>
>> For this particular machine My NOT to build list includes:
>> The following components WILL NOT be built:
>> -----------------------------------------------
>>    Lash support
>>    Python support
>>    Experimental features
>>
>> With kubuntu here it actually does have a python2.pc, no time to check
>> now if that is used.
>
> Correct me if I'm wrong (I know next to nothing about cmake) but
> PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like
> 'pkg-config --modversion python' and then checks that the version
> returned is >= 2.4.
>
> On your kubuntu this shouldn't fail (unless the fact that the .pc file
> is called python2 rather than python confuses cmake) but on Centos or
> Fedora it will always fail given the lack of a .pc file.
>
> I think the cmake python check needs to be rewritten to work everywhere.

Orcan, any thoughts on this?

Regards,
Robert

>
> As I said I have no experience with cmake so unfortunately I can't
> provide you with a patch for this but it would be great if someone with
> cmake experience could look at it.
>
> Regards,
> Andy
>

On Fri, 6 Jul 2012, Robert Jonsson wrote:

> Hi,
> 
> 2012/7/6  <adr-muse@...>:
> > On Fri, 6 Jul 2012, Robert Jonsson wrote:
> >
> >> 2012/7/6  <adr-muse@...>:
> >> > On Fri, 6 Jul 2012, Robert Jonsson wrote:
> >> >
> >> >> Hi Andy,
> >> >>
> >> >> 2012/7/6  <adr-muse@...>:
> >> >> >
> >> >> > Hi,
> >> >> > when I try to build Muse 2.0 on Centos 6.2 (with python and python-devel
> >> >> > installed) cmake tells me it can't detect Python>=2.4 despite Centos 6.2
> >> >> > has Python 2.6 installed.
> >> >> >
> >> >> > 'cmake -L ..' tells me:
> >> >> > -- checking for module 'python>=2.4'
> >> >> > --   package 'python>=2.4' not found
> >> >> > [...]
> >> >> > The following components WILL NOT be built:
> >> >> > -----------------------------------------------
> >> >> >    Python support
> >> >> >    Experimental features
> >> >>
> >> >> That was odd. Must be a bug in the detection. Where is python2.6
> >> >> installed on centos and what is the binary called?
> >> >
> >> > Python is installed in the usual locations, specifically:
> >> > /usr/bin/python
> >> > /usr/bin/python2.6
> >> >
> >> > I think the reason is that Muse is doing a PKG_CHECK_MODULES check for
> >> > python but python (at least python 2.6) doesn't have a pkgconfig (.pc)
> >> > file!
> >> > The python devel package includes a 'python-config' binary in /usr/bin
> >> > which is used instead of the pkgconfig (.pc) file so a cmake
> >> > PKG_CHECK_MODULES will fail.
> >> >
> >> > Isn't this the same on other distros?
> >> >
> >> > Does the python check work on any distro?
> >>
> >> You could be right, atleast partially. It was a while since we
> >> compiled explicitly with python support so it is possible it does not
> >> work, but your error does not happen here.
> >
> > Have you tried running cmake with -DENABLE_PYTHON=1 ?
> > If not, then cmake won't even check for python.
> >
> >
> >> Is the configuration not completed so you could run make anyway?
> >
> > Yes the configuration completes and I can run make and build Muse, but I
> > would like to build it with Python support as this is for a Centos
> > package for my Centos packages repo (http://pkgrepo.linuxtech.net/el6/)
> > which is used by quite a few people, so I like to build the packages
> > with as much functionality enabled as possible.
> >
> 
> I see, in that case you safely skip the python support, it is part of
> the experimental stuff and does not add anything usable in it's
> current state.
>

Ah ok, good to know in that case I won't pursue this further for now.
I will leave python support disabled for the Muse 2.0 package.

Thanks for clarifying this.

Regards,
Andy

>>
>>> For this particular machine My NOT to build list includes:
>>> The following components WILL NOT be built:
>>> -----------------------------------------------
>>>    Lash support
>>>    Python support
>>>    Experimental features
>>>
>>> With kubuntu here it actually does have a python2.pc, no time to check
>>> now if that is used.
>>
>> Correct me if I'm wrong (I know next to nothing about cmake) but
>> PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like
>> 'pkg-config --modversion python' and then checks that the version
>> returned is >= 2.4.
>>
>> On your kubuntu this shouldn't fail (unless the fact that the .pc file
>> is called python2 rather than python confuses cmake) but on Centos or
>> Fedora it will always fail given the lack of a .pc file.
>>
>> I think the cmake python check needs to be rewritten to work everywhere.
>
> Orcan, any thoughts on this?
>

Hmm, it works on Fedora actually. Here, /usr/lib/pkconfig/python.pc is
a symlink to  /usr/lib/pkconfig/python2.pc which is a symlink to
/usr/lib/pkconfig/python-2.7.pc. I am not sure about Ubuntu or CentOS.

What is the suggestion? Check for .python2.pc if python.pc is not found?

Thanks,
Orcan

On Fri, 6 Jul 2012, Orcan Ogetbil wrote:

> >>
> >>> For this particular machine My NOT to build list includes:
> >>> The following components WILL NOT be built:
> >>> -----------------------------------------------
> >>>    Lash support
> >>>    Python support
> >>>    Experimental features
> >>>
> >>> With kubuntu here it actually does have a python2.pc, no time to check
> >>> now if that is used.
> >>
> >> Correct me if I'm wrong (I know next to nothing about cmake) but
> >> PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like
> >> 'pkg-config --modversion python' and then checks that the version
> >> returned is >= 2.4.
> >>
> >> On your kubuntu this shouldn't fail (unless the fact that the .pc file
> >> is called python2 rather than python confuses cmake) but on Centos or
> >> Fedora it will always fail given the lack of a .pc file.
> >>
> >> I think the cmake python check needs to be rewritten to work everywhere.
> >
> > Orcan, any thoughts on this?
> >
> 
> Hmm, it works on Fedora actually. Here, /usr/lib/pkconfig/python.pc is
> a symlink to  /usr/lib/pkconfig/python2.pc which is a symlink to
> /usr/lib/pkconfig/python-2.7.pc. I am not sure about Ubuntu or CentOS.

Actually you are right. It's not a distro thing, it's related to the 
version of python. Starting with Python 2.7 there is a python2.pc file 
included, python 2.6 and earlier didn't have a .pc file.

So since Muse supports python 2.4 or newer, you can't just check for the 
presence of a .pc file, as that would prevent python 2.4 - 2.6 from 
being detected.
 
> What is the suggestion? Check for .python2.pc if python.pc is not found?

That would only detect python 2.7 and newer.

Regards,
Andy

On Fri, Jul 6, 2012 at 8:39 AM, wrote:
> On Fri, 6 Jul 2012, Orcan Ogetbil wrote:
>
>> >>
>> >>> For this particular machine My NOT to build list includes:
>> >>> The following components WILL NOT be built:
>> >>> -----------------------------------------------
>> >>>    Lash support
>> >>>    Python support
>> >>>    Experimental features
>> >>>
>> >>> With kubuntu here it actually does have a python2.pc, no time to check
>> >>> now if that is used.
>> >>
>> >> Correct me if I'm wrong (I know next to nothing about cmake) but
>> >> PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like
>> >> 'pkg-config --modversion python' and then checks that the version
>> >> returned is >= 2.4.
>> >>
>> >> On your kubuntu this shouldn't fail (unless the fact that the .pc file
>> >> is called python2 rather than python confuses cmake) but on Centos or
>> >> Fedora it will always fail given the lack of a .pc file.
>> >>
>> >> I think the cmake python check needs to be rewritten to work everywhere.
>> >
>> > Orcan, any thoughts on this?
>> >
>>
>> Hmm, it works on Fedora actually. Here, /usr/lib/pkconfig/python.pc is
>> a symlink to  /usr/lib/pkconfig/python2.pc which is a symlink to
>> /usr/lib/pkconfig/python-2.7.pc. I am not sure about Ubuntu or CentOS.
>
> Actually you are right. It's not a distro thing, it's related to the
> version of python. Starting with Python 2.7 there is a python2.pc file
> included, python 2.6 and earlier didn't have a .pc file.
>
> So since Muse supports python 2.4 or newer, you can't just check for the
> presence of a .pc file, as that would prevent python 2.4 - 2.6 from
> being detected.
>
>> What is the suggestion? Check for .python2.pc if python.pc is not found?
>
> That would only detect python 2.7 and newer.
>

Then we should search for Python.h I guess. Or maybe there is already
a proper python detection script around for cmake that we can utilize.
This sounds like a common issue.

Thanks, I'll take a look this weekend.

Orcan

On Fri, 6 Jul 2012, Orcan Ogetbil wrote:

> On Fri, Jul 6, 2012 at 8:39 AM, wrote:
> > On Fri, 6 Jul 2012, Orcan Ogetbil wrote:
> >
> >> >>
> >> >>> For this particular machine My NOT to build list includes:
> >> >>> The following components WILL NOT be built:
> >> >>> -----------------------------------------------
> >> >>>    Lash support
> >> >>>    Python support
> >> >>>    Experimental features
> >> >>>
> >> >>> With kubuntu here it actually does have a python2.pc, no time to check
> >> >>> now if that is used.
> >> >>
> >> >> Correct me if I'm wrong (I know next to nothing about cmake) but
> >> >> PKG_CHECK_MODULES(PYTHON python>=2.4) does basically something like
> >> >> 'pkg-config --modversion python' and then checks that the version
> >> >> returned is >= 2.4.
> >> >>
> >> >> On your kubuntu this shouldn't fail (unless the fact that the .pc file
> >> >> is called python2 rather than python confuses cmake) but on Centos or
> >> >> Fedora it will always fail given the lack of a .pc file.
> >> >>
> >> >> I think the cmake python check needs to be rewritten to work everywhere.
> >> >
> >> > Orcan, any thoughts on this?
> >> >
> >>
> >> Hmm, it works on Fedora actually. Here, /usr/lib/pkconfig/python.pc is
> >> a symlink to  /usr/lib/pkconfig/python2.pc which is a symlink to
> >> /usr/lib/pkconfig/python-2.7.pc. I am not sure about Ubuntu or CentOS.
> >
> > Actually you are right. It's not a distro thing, it's related to the
> > version of python. Starting with Python 2.7 there is a python2.pc file
> > included, python 2.6 and earlier didn't have a .pc file.
> >
> > So since Muse supports python 2.4 or newer, you can't just check for the
> > presence of a .pc file, as that would prevent python 2.4 - 2.6 from
> > being detected.
> >
> >> What is the suggestion? Check for .python2.pc if python.pc is not found?
> >
> > That would only detect python 2.7 and newer.
> >
> 
> Then we should search for Python.h I guess.

I agree, searching for Python.h should work in all cases (at least on 
Linux, I have no idea on OS X or Windows).

> Or maybe there is already a proper python detection script around for 
> cmake that we can utilize.
> This sounds like a common issue.

I actually thought of that too and did a web search for it earlier, but 
couldn't find anything that looked right to me, but then that might be 
because of my lack of experience with cmake.
 
> Thanks, I'll take a look this weekend.

That would be great.

Thanks,
Andy

P.S: with regards to your Fedora package:
Does your Fedora Muse binary actually find the Muse libs (the ones in 
%{_libdir}/muse-%{version}/modules/) at runtime?

I had to add '-DCMAKE_SKIP_RPATH=0' as cmake parameter in the %build 
section as the %{cmake} macro on Centos disables RPATHs and therefore 
the Muse binary isn't be able to find it's libs at runtime.

On Fri, Jul 6, 2012 at 5:36 PM, wrote:
> On Fri, 6 Jul 2012, Orcan Ogetbil wrote:
>>
>> Then we should search for Python.h I guess.
>
> I agree, searching for Python.h should work in all cases (at least on
> Linux, I have no idea on OS X or Windows).
>
>> Or maybe there is already a proper python detection script around for
>> cmake that we can utilize.
>> This sounds like a common issue.
>
> I actually thought of that too and did a web search for it earlier, but
> couldn't find anything that looked right to me, but then that might be
> because of my lack of experience with cmake.
>

I found that there is a standard Cmake module
/usr/share/cmake/Modules/FindPythonLibs.cmake that comes with my cmake
installation. A little search revealed that this script has been
around for a while (I saw a record as early as 2005), so I switched to
using this module instead of pkgconfig. Please try out.

>
> P.S: with regards to your Fedora package:
> Does your Fedora Muse binary actually find the Muse libs (the ones in
> %{_libdir}/muse-%{version}/modules/) at runtime?
>

Yes that's the idea.

> I had to add '-DCMAKE_SKIP_RPATH=0' as cmake parameter in the %build
> section as the %{cmake} macro on Centos disables RPATHs and therefore
> the Muse binary isn't be able to find it's libs at runtime.
>

Hmm, insteresting. We also provide a cmake option to build muse as a
single large binary, hence eliminating the need for rpath. This is
enabled by passing  -DMODULES_BUILD_STATIC=1 to cmake. It used to work
just as good. I didn't test it lately though.

Cheers,
Orcan

On Sun, 8 Jul 2012, Orcan Ogetbil wrote:

> On Fri, Jul 6, 2012 at 5:36 PM, wrote:
> > On Fri, 6 Jul 2012, Orcan Ogetbil wrote:
> >>
> >> Then we should search for Python.h I guess.
> >
> > I agree, searching for Python.h should work in all cases (at least on
> > Linux, I have no idea on OS X or Windows).
> >
> >> Or maybe there is already a proper python detection script around for
> >> cmake that we can utilize.
> >> This sounds like a common issue.
> >
> > I actually thought of that too and did a web search for it earlier, but
> > couldn't find anything that looked right to me, but then that might be
> > because of my lack of experience with cmake.
> >
> 
> I found that there is a standard Cmake module
> /usr/share/cmake/Modules/FindPythonLibs.cmake that comes with my cmake
> installation. A little search revealed that this script has been
> around for a while (I saw a record as early as 2005), so I switched to
> using this module instead of pkgconfig. Please try out.

Ok, I tried a current SVN checkout but it still doesn't work 100%.
Now I get:

cmake .. -DENABLE_PYTHON=1
[...]
-- checking for module 'lash-1.0>=0.2'
--   found lash-1.0, version 0.5.4
-- checking for module 'liblo>=0.23'
--   found liblo, version 0.26
-- Found PythonLibs: /usr/lib64/python2.6/config/libpython2.6.so
-- checking for module 'dssi>=0.9.0'
--   found dssi, version 1.1.1
-- checking for module 'fluidsynth>=0.9.0'
--   found fluidsynth, version 1.1.5

The following components will be built:
-----------------------------------------------
   Lash support
   OSC (Liblo) support
   DSSI support
   Fluidsynth support

The following components WILL NOT be built:
-----------------------------------------------
   Python support
   Experimental features

So it finds Python but it still doesn't enable it.
I guess the version check doesn't work as expected.
 

> > I had to add '-DCMAKE_SKIP_RPATH=0' as cmake parameter in the %build
> > section as the %{cmake} macro on Centos disables RPATHs and therefore
> > the Muse binary isn't be able to find it's libs at runtime.
> >
> 
> Hmm, insteresting. We also provide a cmake option to build muse as a
> single large binary, hence eliminating the need for rpath. This is
> enabled by passing  -DMODULES_BUILD_STATIC=1 to cmake. It used to work
> just as good. I didn't test it lately though.

I prefer using '-DCMAKE_SKIP_RPATH=0' than building a static binary, but 
I'm surprised that on Fedora it works without '-DCMAKE_SKIP_RPATH=0'.

Does the %{cmake} macro on Fedora not have '-DCMAKE_SKIP_RPATH:BOOL=ON'?

Regards,
Andy

On Sun, Jul 8, 2012 at 3:17 AM,  wrote:
> On Sun, 8 Jul 2012, Orcan Ogetbil wrote:
>> I found that there is a standard Cmake module
>> /usr/share/cmake/Modules/FindPythonLibs.cmake that comes with my cmake
>> installation. A little search revealed that this script has been
>> around for a while (I saw a record as early as 2005), so I switched to
>> using this module instead of pkgconfig. Please try out.
>
> Ok, I tried a current SVN checkout but it still doesn't work 100%.
> Now I get:
>
> cmake .. -DENABLE_PYTHON=1
> [...]
> -- checking for module 'lash-1.0>=0.2'
> --   found lash-1.0, version 0.5.4
> -- checking for module 'liblo>=0.23'
> --   found liblo, version 0.26
> -- Found PythonLibs: /usr/lib64/python2.6/config/libpython2.6.so
> -- checking for module 'dssi>=0.9.0'
> --   found dssi, version 1.1.1
> -- checking for module 'fluidsynth>=0.9.0'
> --   found fluidsynth, version 1.1.5
>
> The following components will be built:
> -----------------------------------------------
>    Lash support
>    OSC (Liblo) support
>    DSSI support
>    Fluidsynth support
>
> The following components WILL NOT be built:
> -----------------------------------------------
>    Python support
>    Experimental features
>
> So it finds Python but it still doesn't enable it.
> I guess the version check doesn't work as expected.
>
>

Okay, I found a CentOS box to ssh to. Apparently CentOS' cmake is old
enough that some of the cmake macros do not get defined as expected. I
added a slightly smarter Python detection routine for older cmake.
Please try it again.

>> > I had to add '-DCMAKE_SKIP_RPATH=0' as cmake parameter in the %build
>> > section as the %{cmake} macro on Centos disables RPATHs and therefore
>> > the Muse binary isn't be able to find it's libs at runtime.
>> >
>>
>> Hmm, insteresting. We also provide a cmake option to build muse as a
>> single large binary, hence eliminating the need for rpath. This is
>> enabled by passing  -DMODULES_BUILD_STATIC=1 to cmake. It used to work
>> just as good. I didn't test it lately though.
>
> I prefer using '-DCMAKE_SKIP_RPATH=0' than building a static binary, but
> I'm surprised that on Fedora it works without '-DCMAKE_SKIP_RPATH=0'.
>
> Does the %{cmake} macro on Fedora not have '-DCMAKE_SKIP_RPATH:BOOL=ON'?
>

Yes it got removed some time ago. I don't recall the exact reasoning.
Possibly because of some similar scenario to which we depend on Muse.
http://pkgs.fedoraproject.org/gitweb/?p=cmake.git;a=commit;h=3724c3c21b

Cheers,
Orcan

On Sun, 8 Jul 2012, Orcan Ogetbil wrote:

> On Sun, Jul 8, 2012 at 3:17 AM,  wrote:
> > On Sun, 8 Jul 2012, Orcan Ogetbil wrote:
> >> I found that there is a standard Cmake module
> >> /usr/share/cmake/Modules/FindPythonLibs.cmake that comes with my cmake
> >> installation. A little search revealed that this script has been
> >> around for a while (I saw a record as early as 2005), so I switched to
> >> using this module instead of pkgconfig. Please try out.
> >
> > Ok, I tried a current SVN checkout but it still doesn't work 100%.
> > Now I get:
> >
> > cmake .. -DENABLE_PYTHON=1
> > [...]
> > -- checking for module 'lash-1.0>=0.2'
> > --   found lash-1.0, version 0.5.4
> > -- checking for module 'liblo>=0.23'
> > --   found liblo, version 0.26
> > -- Found PythonLibs: /usr/lib64/python2.6/config/libpython2.6.so
> > -- checking for module 'dssi>=0.9.0'
> > --   found dssi, version 1.1.1
> > -- checking for module 'fluidsynth>=0.9.0'
> > --   found fluidsynth, version 1.1.5
> >
> > The following components will be built:
> > -----------------------------------------------
> >    Lash support
> >    OSC (Liblo) support
> >    DSSI support
> >    Fluidsynth support
> >
> > The following components WILL NOT be built:
> > -----------------------------------------------
> >    Python support
> >    Experimental features
> >
> > So it finds Python but it still doesn't enable it.
> > I guess the version check doesn't work as expected.
> >
> >
> 
> Okay, I found a CentOS box to ssh to. Apparently CentOS' cmake is old
> enough that some of the cmake macros do not get defined as expected. I
> added a slightly smarter Python detection routine for older cmake.
> Please try it again.

Perfect, thanks, now it works fine!

This is what i get now when I run:
cmake .. -DENABLE_PYTHON=1


The following components will be built:
-----------------------------------------------
   Lash support
   OSC (Liblo) support
   Python support
   DSSI support
   Fluidsynth support

The following components WILL NOT be built:
-----------------------------------------------
   Experimental features

 
> >> > I had to add '-DCMAKE_SKIP_RPATH=0' as cmake parameter in the %build
> >> > section as the %{cmake} macro on Centos disables RPATHs and therefore
> >> > the Muse binary isn't be able to find it's libs at runtime.
> >> >
> >>
> >> Hmm, insteresting. We also provide a cmake option to build muse as a
> >> single large binary, hence eliminating the need for rpath. This is
> >> enabled by passing  -DMODULES_BUILD_STATIC=1 to cmake. It used to work
> >> just as good. I didn't test it lately though.
> >
> > I prefer using '-DCMAKE_SKIP_RPATH=0' than building a static binary, but
> > I'm surprised that on Fedora it works without '-DCMAKE_SKIP_RPATH=0'.
> >
> > Does the %{cmake} macro on Fedora not have '-DCMAKE_SKIP_RPATH:BOOL=ON'?
> >
> 
> Yes it got removed some time ago. I don't recall the exact reasoning.
> Possibly because of some similar scenario to which we depend on Muse.
> http://pkgs.fedoraproject.org/gitweb/?p=cmake.git;a=commit;h=3724c3c21b

OK, that explains it.

Regards,
Andy

2012/7/7 Andy <adr-muse@...>:
> Hi,
>
> just wanted to let you know that I have now released my 32 and 64 bit
> RPM packages of Muse 2.0 for Centos / Redhat / Scientific Linux 6.x.
>
> The packages are available from my personal repo at:
> http://pkgrepo.linuxtech.net/el6/
>
> They are currently located in the 'testing' repo but I will move them to
> the 'release' repo in a few days once I have tested them a bit more.
>
> The recommended way to install them is to add my repo to your configured
> repos and then use 'yum install', so that all dependecies get installed
> automatically, too.
>
> See also this related forum thread with more details:
> http://scientificlinuxforum.org/index.php?showtopic=1726
>
> Have fun with Muse!

Marvelous!

/Robert