Issue 10 in synthclone: Please make configure script lib64 saavy

[synth...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 10 by simon...@slnet-online.de: Please make configure script
lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Please add the variable libdir to the configure script so that I can parse
the command

./configure --prefix=/usr --libdir=/usr/lib64

[synth...@googlecode.com]

Comment #1 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Sorry, found the following solution:

qmake -makefile synthclone.pro
make

[synth...@googlecode.com]

Comment #2 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Issue 11 has been merged into this issue.

[synth...@googlecode.com]

Comment #3 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

I'm confused as to how the solution you suggested helps synthclone to be
built with libraries put in /usr/lib64.

I think that what probably needs to happen is 'synthclone.pri' needs to be
changed so that:

1.) 'CONFIG += x86_64' is added for 64-bit builds
2.) 'SYNTHCLONE_LIBRARY_SUFFIX' is set to 'lib64' for 64-bit builds
3.) 'SYNTHCLONE_PLUGIN_SUFFIX' is set to 'lib64/synthclone/plugins' for
64-bit builds

I need to do a bit more research to confirm whether or not I'm correct. In
the meantime, I'd like to hear your thoughts on how to solve the problem.

[synth...@googlecode.com]

Comment #4 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Then again, maybe there's a good reason to add a 'libdir' flag to the
`configure` script. Hmmm.

[synth...@googlecode.com]

Comment #5 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Try applying this patch and rebuilding. I don't have a 64-bit machine to
test it on. If it works, then I'll commit it and bump the revision.

Attachments:
64bit.diff 818 bytes

[synth...@googlecode.com]

Comment #6 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Scratch that. Try this patch instead. If it works, it will handle plugins
properly.

Attachments:
64bit.diff 3.2 KB

[synth...@googlecode.com]

Comment #7 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

On Issue #11, you posted:

Sorry, cannot make head or tail of the error message:

make[1]: *** [sub-plugins-make_default-ordered] Error 2
make[1]: Leaving directory
`/home/simon/rpmbuild/BUILD/synthclone-0.2.0/src'
make: *** [sub-src-make_default] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.H0y1Ph (%build)

... and then you said that the project just wasn't 64-bit savvy
because "The make is looking for libportmidi under /usr/lib and not
/usr/lib64".

I don't have all of the output from the command you ran (please post all
the output instead of just the error message next time), but if the build
failed at the point of looking for libportmidi and not before that point,
then that means that libsynthclone, the Hydrogen plugin, and the JACK
plugin all built fine on the 64-bit machine, which means that
libsamplerate, Qt, and JACK were linked into various components of
synthclone without problems.

This begs the question: if these other components built correctly in this
environment, then why did the build that relied on libportmidi fail?

Can you please post the complete output of your RPM build?

Thanks.

[synth...@googlecode.com]

Comment #8 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Not quite there but getting better...

- Sorry guys, I think I set a force trail in that I had mistakenly
installed the 32bit and not the 64 bit package of portmidi-devel

- Using the normal ./configure plus the diff doesn't get very far - see log
attached

- Using the following without diff builds but fails at the install into the
build root - see log attached

export PATH=${PATH}:%{_libdir}/qt4/bin
qmake -makefile synthclone.pro
%__make %{?_smp_mflags}
%__make DESTDIR=%{buildroot} install

- I guess I need to pass some arguments to the qmake something like
-DQMAKE_PREFIX=%{_prefix} and -DQMAKE_INSTALL_DIR=%{buildroot} but I quite
quite work it out.

I also attached the makefile generated by qmake.

I'm very grateful for all the help you can give, with best regards Simon


Attachments:
synthclone-konsole-configure+patch.log 2.8 KB
synthclone-konsole-qmake.log 135 KB
Makefile 7.0 KB

[synth...@googlecode.com]

Comment #9 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

This is very helpful. :)

Here are some hints to help make the build successful:

1.) Read the following to understand the packaging scheme used by
`synthclone`:

http://code.google.com/p/synthclone/source/browse/README.PACKAGING

2.) You'll find that you won't be able to use the normal 'configure', as
this isn't an autotools project.

3.) The first error in your qmake log is:

mkdir: cannot create directory `/usr/local/include/synthclone/':
Permission denied

I'm assuming this is happening during:

%__make DESTDIR=%{buildroot} install

Try changing this line to read:

%__make install INSTALL_ROOT=%{buildroot}

4.) The qmake line should be a './configure' line. Something as simple as:

./configure --prefix=/usr

... will probably work out. If specifying the library directory is really
necessary, then we can talk about adding it to the configure script.

Hope this helps. :)

Out of question, for what distribution(s) are you building `synthclone`?

[synth...@googlecode.com]

Comment #10 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Thanks for the quick response - I'm using fedora 16 however this applies
equally to opensuse, mandriva, mageia, centos etc..

The configure file is a no-goer as its too debian specific and not a
universal set-up

The following, as a first step works:

export PATH=${PATH}:%{_libdir}/qt4/bin

qmake -makefile synthclone.pro PREFIX=%{_prefix}
pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd
%__make %{?_smp_mflags}
%__make install INSTALL_ROOT=%{buildroot}

However I need to move a lot of files around according to the following
rules:

PREFIX=/usr
LIBDIR=/usr/lib64 (x86_64) /usr/lib (i686)
INCLUDEDIR=/usr/include
DATADIR=/usr/share

(Debian also uses the concepts LIBDIR INCLUDEDIR DATADIR)

Thanks for all your help up to now.

With best regards, Simon Lewis

[synth...@googlecode.com]

Comment #11 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

AFAIK, the configure file doesn't have anything that's Debian-specific.

However, you're correct that the configuration file is not universal. I'd
certainly like to get it closer to being universal, which is why I'm asking
questions, and would like to get the configure file to support your
use-case.

I have a couple questions:

1.) What does this:

pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd

... do for you that this:

qmake -makefile synthclone.pro PREFIX=%{_prefix}

... doesn't already do?

2.) Why can't you just do this:

./configure --prefix=%{_prefix}

... instead of this:

qmake -makefile synthclone.pro PREFIX=%{_prefix}
pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd

AFAICT, the configure command does all the same things the qmake commands
do, and it adds 'config.h' to the header files.

[synth...@googlecode.com]

Comment #12 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Hi

Here is the answer to question 2:

[simon@spaceloopxl synthclone-0.2.0]$ ./configure --prefix=/usr
Traceback (most recent call last):
File "./configure", line 125, in <module>
main()
File "./configure", line 118, in main
if call(qmakeArgs):
File "/usr/lib64/python2.7/subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
[simon@spaceloopxl synthclone-0.2.0]$

As to question 1, I doubled checked the build process with qmake and found
that on make that the makefile for the sources is rewritten, so you are
right, I don't need the detour in the sources directory before building.

New point 3. A good example of a configure file that build on all
distrubutions and has done so for years is Qtractor. Perhaps there is a
trick or two to be learned there.

With best regards, Simon


r

[synth...@googlecode.com]

Comment #13 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

I believe the error above happens because qmake isn't in your path. So,
this:

export PATH=${PATH}:%{_libdir}/qt4/bin

./configure --prefix=%{_prefix}

%__make %{?_smp_mflags}
%__make install INSTALL_ROOT=%{buildroot}

... should work.


I'll take a look at qtractor.

[synth...@googlecode.com]

Comment #14 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Unfortunately, looking at Qtractor's build setup isn't very helpful. The
build process for Qtractor isn't nearly as complex as the build process for
`synthclone`, as Qtractor doesn't have a development API, headers, and
plugins based on its development API.

I'd really like to see what you're working on. Is there a public link
available?

[synth...@googlecode.com]

Comment #15 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Hi

The build project can be cloned from:

https://build.opensuse.org/package/show?package=Synthclone&project=home%3AWilliamSimonLewis

As you will see the build was successful - there are few minor hacks in the
spec file.

However, when starting the app the following message was received:

[simon@spaceloopxl ~]$ /usr/bin/synthclone
"Translations loaded."
"Creating core application objects ..."
Error: core plugin directory is not accessible
"Unloading translations ..."
[simon@spaceloopxl ~]$

I'm guessing that the lib path is also hard-wired in the sources as well...

The build was made using qmake - which is common practice when making
packages.

[synth...@googlecode.com]

Comment #16 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

I understand that it's common to use `qmake` to make packages. The
`configure` script is just a wrapper around `qmake`. It does some things
that `qmake` can't elegantly do on its own, including creating a config.h
header file. Please use the `configure` script, as it's more versatile,
and more likely to work correctly for builds now and in the future.

It's become clear that I need to add some sort of --libdir option to the
configure script.

You're right; the 'lib' path is (currently) hardwired in the sources. For
now, you can solve the plugin directory error by modifying line 747 of
src/synthclone/controller.cpp to read:

if (pluginDirectory.cd("lib64")) {

I'll put some effort today into solving this problem in a more elegant
fashion.

There are some recommendations in the 'README.PACKAGING' file regarding
separating `synthclone` into application and development packages.

[synth...@googlecode.com]

Comment #17 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Please do not rename the 'synthclone-devel' documentation directory with
any name that implies that the documents are not strictly development
documents. The directory holds doxygen-generated documentation on the
synthclone plugin API. If and when there is actual help documentation for
the application, then it will be put in a directory with a name that will
be similar to the one you're using to rename the development documentation
directory. A suitable name that's similar might be:

share/doc/%{name}-dev-%{version}

This is more consistent with separating `synthclone` into application and
development packages.

I really appreciate that you're doing this, and I hope I'm not coming
across as a micro-managing type (if so, I apologize). Thank you for
putting forth the effort to make `synthclone` available to a wider
audience. :)

[synth...@googlecode.com]

Comment #18 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Please take a look at...

https://build.opensuse.org/package/binaries?package=Synthclone&project=home%3AWilliamSimonLewis&repository=Fedora_16

[synth...@googlecode.com]

Comment #19 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

I think it looks great! I do have one question about the spec file, and
I'm not totally familiar with the RPM format, so maybe I'll end up learning
something by asking this question ...

Does each file that's installed need to be in the files section? I was
looking for references to the development API documentation, and I saw a
`sed` command that renamed the directory, but didn't see it referenced in
the files section.

I'm really excited about seeing `synthclone` be available for download as
an RPM! Will you be submitting the RPM to Fedora and/or any other
distributions?

Thanks again for putting forth the effort to do this. :) When I figure out
how I want to handle the `configure` script with regards to library
directories, I'll let you know.

[synth...@googlecode.com]

Comment #20 on issue 10 by simon...@slnet-online.de: Please make

configure script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Yes, the build fails if one or more files in the buildroot are not include
in one of the package files lists.

In this spec file I used the %doc script to automatically pick-up the files
in the %_docdir. It is both a fedora and openSUSE requirement to use
the %doc script - plus it saves listing the files individually...

[synth...@googlecode.com]

Updates:
Status: Started

Comment #21 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

Hi Simon,

I know it's been a while, but I thought I'd let you know that my latest
commit contains what I believe is a more user-friendly configure script.
If and when you have some time, then I'd like to know if you think that the
configure script is now friendly to packagers that are creating packages
for 64-bit platforms. If the configure script is acceptable, then I'll go
ahead and make a release and close this issue.

Thanks in advance.

[synth...@googlecode.com]

Updates:
Status: Fixed

Comment #22 on issue 10 by surfacep...@gmail.com: Please make configure

script lib64 saavy
http://code.google.com/p/synthclone/issues/detail?id=10

I think I've given enough time for a response. I'm closing this issue.