You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by LONGO Matthieu <Ma...@murex.com> on 2017/12/21 15:19:25 UTC
build dependencies of apr-util
Hello,
I built APR 1.6.3 and APR-util 1.6.1 and noticed dependencies to files located in APR's repository.
buildconf: l.61
# Remove some files, then copy them from apr source tree
rm -f build/apr_common.m4 build/find_apr.m4 build/install.sh \
build/config.guess build/config.sub build/get-version.sh
cp -p $apr_src_dir/build/apr_common.m4 $apr_src_dir/build/find_apr.m4 \
$apr_src_dir/build/install.sh $apr_src_dir/build/config.guess \
$apr_src_dir/build/config.sub $apr_src_dir/build/get-version.sh \
build/
buildconf: l.90
echo "Generating 'make' outputs ..."
$apr_src_dir/build/gen-build.py $verbose make
Why are these files not directly included in apr-utils's repository if they are necessary for the build ?
In my opinion, if apr-utils depends on apr, I should firstly build apr as follow:
./buildconf
./configure --prefix=/usr
make && make install
Since apr's libraries and headers are installed in standard pathes, I should be able to
build apr-util directly without having to specify the location of the sources of apr.
./buildconf --with-apr=/usr
./configure --prefix=/usr
make && make install
My real use case is the packaging of apr and apr-util with conan (http://docs.conan.io/en/latest/)
You can find here below the recipes (note: the one for apr-util does not work because of what I mentioned above)
conan recipe for APR:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from conans import ConanFile, tools, AutoToolsBuildEnvironment
class APRConan(ConanFile):
name = "apr"
version = "1.6.3"
description = "..."
license = "http://www.apache.org/licenses/LICENSE-2.0"
url = "https://.../conan-apr.git"
settings = "os", "compiler", "build_type", "arch"
options = {"PIC": [True, False], "shared": [True, False]}
default_options = "PIC=True", "shared=False"
source_dir = "apache-{}-{}".format(name, version)
def source(self):
repo_url = "https://.../apache-apr.git"
self.run("git clone {} {}".format(repo_url, self.source_dir))
def build(self):
env_build = AutoToolsBuildEnvironment(self)
with tools.chdir(self.source_dir):
args = []
if not self.options['shared']:
args.append('--disable-shared')
args.append('--prefix={}'.format(self.package_folder))
self.run('./buildconf')
env_build.configure(args=args)
env_build.make()
env_build.make(args=['install'])
def package(self):
# already done by make install
pass
def package_info(self):
self.cpp_info.includedirs = ['include']
self.cpp_info.libdirs = ['lib']
self.cpp_info.bindirs = ['bin']
self.cpp_info.resdirs = ['build-1']
self.cpp_info.libs = ["apr-1"]
conan recipe for APR util:
#/usr/bin/env python
# -*- coding: utf-8 -*-
from os import path
from conans import CMake, ConanFile, tools, AutoToolsBuildEnvironment
class APRConan(ConanFile):
name = "apr-util"
version = "1.6.1"
description = "..."
license = "http://www.apache.org/licenses/LICENSE-2.0"
url = "https://.../conan-apr-util.git"
settings = "os", "compiler", "build_type", "arch"
options = {"PIC": [True, False], "shared": [True, False]}
default_options = "PIC=True", "shared=False"
source_dir = "apache-{}-{}".format(name, version)
build_requires = "apr/1.6.3@matthieu/testing"
def source(self):
repo_url = "https://.../apache-apr-util.git"
self.run("git clone {} {}".format(repo_url, self.source_dir))
def build(self):
env_build = AutoToolsBuildEnvironment(self)
with tools.chdir(self.source_dir):
apr_prefix = self.deps_cpp_info['apr'].rootpath
args = []
args.append('--prefix={}'.format(self.package_folder))
#args.append('--with-apr={}'.format(apr_prefix))
self.run('./buildconf --with-apr={}'.format(apr_prefix))
env_build.configure(args=args)
env_build.make()
env_build.make(args=['install'])
def package(self):
# already done by make install
pass
def package_info(self):
self.cpp_info.includedirs = ['include']
self.cpp_info.libdirs = ['lib']
self.cpp_info.bindirs = ['bin']
self.cpp_info.libs = ["apr-util-1"]
What do you think about making the build of APR util more independent ?
Regards,
Matthieu
*******************************
This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
Re: build dependencies of apr-util
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Dec 21, 2017 at 12:06 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Dec 21, 2017 at 9:19 AM, LONGO Matthieu
> <Ma...@murex.com> wrote:
>> Hello,
>>
>> I built APR 1.6.3 and APR-util 1.6.1 and noticed dependencies to files located in APR's repository.
>>
>> buildconf: l.61
>> # Remove some files, then copy them from apr source tree
>> rm -f build/apr_common.m4 build/find_apr.m4 build/install.sh \
>> build/config.guess build/config.sub build/get-version.sh
>> cp -p $apr_src_dir/build/apr_common.m4 $apr_src_dir/build/find_apr.m4 \
>> $apr_src_dir/build/install.sh $apr_src_dir/build/config.guess \
>> $apr_src_dir/build/config.sub $apr_src_dir/build/get-version.sh \
>> build/
>>
>> buildconf: l.90
>> echo "Generating 'make' outputs ..."
>> $apr_src_dir/build/gen-build.py $verbose make
>>
>> Why are these files not directly included in apr-utils's repository if they are necessary for the build ?
>>
>> In my opinion, if apr-utils depends on apr, I should firstly build apr as follow:
>> ./buildconf
>
> That's where you became confused, or we led you astray...
>
> ./buildconf is not a necessary step of building apr-util from the
> released source
> tarball. And configuration does not entitle automake-style maintainer-mode
> (this is straight autoconf), so ./buildconf will not reoccur when building on an
> unusual platform with poor AC support or without an AC toolchain.
>
> Yes, it is necessary to have sources from apr for the release manager to
> package apr-util. That's simply not part of the source tree and not necessary
> as a typical end-user activity. Proceed directly to configure when building
> from the source tarballs.
[There is a footnote to this,
https://bz.apache.org/bugzilla/show_bug.cgi?id=51215
as proposed should resolve a host of related issues for users who wish to
rebuild the apr-util config.]
Re: build dependencies of apr-util
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Dec 21, 2017 at 9:19 AM, LONGO Matthieu
<Ma...@murex.com> wrote:
> Hello,
>
> I built APR 1.6.3 and APR-util 1.6.1 and noticed dependencies to files located in APR's repository.
>
> buildconf: l.61
> # Remove some files, then copy them from apr source tree
> rm -f build/apr_common.m4 build/find_apr.m4 build/install.sh \
> build/config.guess build/config.sub build/get-version.sh
> cp -p $apr_src_dir/build/apr_common.m4 $apr_src_dir/build/find_apr.m4 \
> $apr_src_dir/build/install.sh $apr_src_dir/build/config.guess \
> $apr_src_dir/build/config.sub $apr_src_dir/build/get-version.sh \
> build/
>
> buildconf: l.90
> echo "Generating 'make' outputs ..."
> $apr_src_dir/build/gen-build.py $verbose make
>
> Why are these files not directly included in apr-utils's repository if they are necessary for the build ?
>
> In my opinion, if apr-utils depends on apr, I should firstly build apr as follow:
> ./buildconf
That's where you became confused, or we led you astray...
./buildconf is not a necessary step of building apr-util from the
released source
tarball. And configuration does not entitle automake-style maintainer-mode
(this is straight autoconf), so ./buildconf will not reoccur when building on an
unusual platform with poor AC support or without an AC toolchain.
Yes, it is necessary to have sources from apr for the release manager to
package apr-util. That's simply not part of the source tree and not necessary
as a typical end-user activity. Proceed directly to configure when building
from the source tarballs.
Cheers,
Bill