From: Jens Axboe <axboe@kernel.dk>
To: Daniel Gollub <d.gollub@telekom.de>, fio@vger.kernel.org
Subject: Re: fio headers as build dependency for external-ioengines
Date: Wed, 30 Apr 2014 08:29:15 -0600 [thread overview]
Message-ID: <536108BB.7030502@kernel.dk> (raw)
In-Reply-To: <1398849904-6013-1-git-send-email-d.gollub@telekom.de>
On 04/30/2014 03:25 AM, Daniel Gollub wrote:
> Hi,
>
> I am working right now in preparing for the Ceph project an external
> fio ioengine, which depends on Ceph-internal libraries. So I thought
> about building this ioengine as an external ioengine. (Thats why I
> send couple of weeks/month ago this C++-compiler-issues-fixes for
> fio.h)
>
> Since fio is not (yet) distributed with a -dev/-devel package in
> linux distribution and was very likely not yet consider doing so
> I wanted to start the discussion here if this in interested of the
> project "exporting"/"installing" the required fio headers to build
> external ioengines. So fio can be later a "packaged" build-dependency.
>
> For time-being I thought about solving this like this:
>
> One can introduce in the external project's build-env a parameter
> like: --with-fio=~/projects/fio/ and the resulting build-env will
> pass this path as include directory as compiler flags for the
> external ioengine build.
>
> Unfortunately there are some issues with double-declaration and
> one ambiguous header file name (e.g. time.h - see provided patch)
>
> Double-declaration issues of defines/macros/... I hit while building
> the Ceph filestore external ioengine:
>
> * ARRAY_SIZE
> * CONFIG_CPU_COUNT
> * le16_to_cpu
> * le32_to_cpu
> * le64_to_cpu
>
>
> If you want to reproduce the described issue with ceph,
> checkout following revision:
> https://github.com/gollub/ceph/commit/079c08c67f811c0173e70201dc91168b60d2e86b
> ( Working branch: https://github.com/gollub/ceph/tree/fio_filestore_v2 )
>
> And run:
> ./configure --with-fio-dir=/path/to/fio/
> cd src
> make libfio_ceph_filestore.la
>
>
> This could be solved/workaround on the external ioengine side, as well
> as in the fio header. One possibility on the fio side could be to relax
> fio.h header a bit, so only mandatory declarations and further
> includes are part of it to successfully build an external-ioengine.
> I am happy to help on this if fio decides to go this route.
>
> Thoughts?
It'd be a useful thing to be able to do. I applied your time patch,
looks fine to me. Are you going to be able to work through the other
issues? I think we just need to privatize some of the names a bit more.
--
Jens Axboe
prev parent reply other threads:[~2014-04-30 14:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 9:25 fio headers as build dependency for external-ioengines Daniel Gollub
2014-04-30 9:25 ` [PATCH] Rename time.h for third-party include of fio.h Daniel Gollub
2014-04-30 14:29 ` Jens Axboe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536108BB.7030502@kernel.dk \
--to=axboe@kernel.dk \
--cc=d.gollub@telekom.de \
--cc=fio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox