From: Owen Synge <osynge@suse.com>
To: Ken Dreyer <kdreyer@redhat.com>, Sage Weil <sweil@redhat.com>,
Loic Dachary <loic@dachary.org>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: what this would look like if the system is with templates.
Date: Wed, 10 Jun 2015 12:44:30 +0200 [thread overview]
Message-ID: <5578150E.2070007@suse.com> (raw)
In-Reply-To: <55777164.6090201@redhat.com>
On 06/10/2015 01:06 AM, Ken Dreyer wrote:
> On 06/09/2015 11:19 AM, Owen Synge wrote:
>>
>>> we can be remove many hard coded values replaced with variable and that
>>> probably will only grow in number for example
>>>
>>> %if 0%{?rhel} || 0%{?fedora}
>>> --with-systemd-libexec-dir=/usr/libexec/ceph \
>>> %endif
>>> %if 0%{?opensuse} || 0%{?suse_version}
>>> --with-systemd-libexec-dir=/usr/lib/ceph/ \
>>> %endif
>>
>> --with-systemd-libexec-dir=@systemd_libexec_dir@ \
>>
>> No OS distribution specific rubbish needed :)
>
> Passing an autoconf variable (@systemd_libexec_dir@) to an autoconf
> argument (--with-systemd-libexec-dir) seems really over-complicated to me.
It makes separating things like version info from function hard.
The %else function is a minefield.
The %if statements around nearly every line in configure give you a hint
of the problem.
Autotools is not the last word in pretty language but it does warn when
you do platform specific stuff very well, and its a lot more flexible
than rpm.
> I don't see the issues with putting os-specific things in the .spec
> file; that's how many other (non-Ceph) projects do it.
These conditionals do not occur just done once if used in the spec.in
file though its worse, you need the same conditionals on each of
configure
files
install
Admittedly if we follow the current process of deprecating direct
platform based installs we can get the conditionals down to two places
in the spec.in file rather than 3.
I think having the conditionals set in one place is superior to 2 or 3
places. To do this you would template the rpm spec file.
Best regards
Owen
next prev parent reply other threads:[~2015-06-10 10:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 8:34 Configure dependencies can be the same as make dependencies Loic Dachary
2015-05-05 14:31 ` Gregory Farnum
2015-05-05 14:36 ` Loic Dachary
2015-05-05 18:59 ` Ken Dreyer
2015-05-05 19:07 ` Loic Dachary
2015-05-05 19:31 ` Sage Weil
2015-06-09 17:11 ` Owen Synge
2015-06-09 17:19 ` what this would look like if the system is with templates Owen Synge
2015-06-09 23:06 ` Ken Dreyer
2015-06-10 10:44 ` Owen Synge [this message]
2015-06-09 17:22 ` Configure dependencies can be the same as make dependencies Sage Weil
2015-06-09 18:23 ` Owen Synge
2015-06-09 18:44 ` Sage Weil
2015-06-09 19:23 ` Owen Synge
2015-05-05 17:15 ` Kefu Chai
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=5578150E.2070007@suse.com \
--to=osynge@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=kdreyer@redhat.com \
--cc=loic@dachary.org \
--cc=sweil@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.