Post by Colin PercivalPost by Peter PentchevWow... I haven't taken a look at your packaging yet, but it seems that
there has been a bit of a duplication of effort :) I filed a Debian ITP
(intent to package) bug on the same day spiped came out, and I'm almost
ready with my package at http://gitorious.org/spiped/spiped :)
Hi Colin, Andreas,
After a quite unfortunate delay of three months, for which I can only
apologize again most sincerely, here's an updated version of my work on
packaging spiped-1.2.2 for Debian - and a couple of attached patches for
Colin's review and possible inclusion upstream.
The whole Debian package is, again, available at
http://gitorious.org/spiped/spiped/commits/debian
git://gitorious.org/spiped/spiped.git -b debian
Post by Colin Percival1. I agree with Andreas that setting compiler and linker flags in the
environment or make command line is better than patching the Makefiles...
after all, I specifically put bits in to let you do that.
With all due respect, I have to disagree here, but only a bit :)
Of course, if this were only about passing new values to CFLAGS or
LDFLAGS_EXTRA, I would be all for it - and that's what the Debian
package does with CFLAGS. However, IMHO the upstream build system
should also handle CPPFLAGS and LDFLAGS, not just CFLAGS, for a couple
of reasons:
- even if right now the spiped source doesn't need the distinction
between C compiler and preprocessor flags, it might very well arise in
the future; for several of my projects, it arose when I realized that
I do need some (but not all!) of the definitons at the "make depend"
stage, when only the preprocessor is invoked. It makes no real sense
to pass debugging, optimization, etc flags to the C preprocessor at
that stage, and some of the environment's settings really do need to
be passed. Again, spiped doesn't need this right now, but IMHO it'll
do no harm.
- in Debian's case, there *are* some settings that the build environment
passes in CPPFLAGS and not CFLAGS, and they really do need to make it
into the build system - mostly build hardening flags that are, at the
present, strongly encouraged if not outright compulsory as defined by
the Debian Policy document. Of course, this could've been handled
very well by adding a simple CFLAGS+= ${CPPFLAGS} in the Debian build
infrastructure and letting spiped's build system just listen to CFLAGS
as it already does, but this way - honoring the conventional way of
passing C preprocessor flags - seems a bit cleaner to me personally.
- finally, a kind of weak argument, but... at least in my software, I've
(gradually, I have to admit! :) consciously built a habit of following
the conventions - and over the years I have formed the personal
opinion that *most* conventions call for CPPFLAGS, CFLAGS and LDFLAGS
as separate variables with those most common names. With lots of
build and packaging systems in all kinds of OSs and distributions, it
seems easier to me to just honor the flags passed in those variables
if they are available.
Post by Colin Percival2. Similarly, can you add -D_POSIX_C_SOURCE=200809L to CFLAGS instead of
patching source code?
Yes, I do have to admit that this was a momentary lapse of reason on my
part. Of *course* it's easier to pass them as flags instead of patching
all the source files that *seem* to need them. Furthermore, when I did
that and passed them in the global preprocessor flags, it turned out
that I was quite mistaken in shunting out the posix-l.sh invocation
because it had seemed to me at the time that Debian doesn't need librt -
well, with a proper _POSIX_C_SOURCE definition, Debian does want
functions that only exist there :) So I restored that.
Now... Once again, it is my personal opinion that the POSIX compliance
flags should be set in the spiped build system, so that it is easier for
people to build it in any POSIX-compliant C environment without the
explicit need of passing more flags. There is no harm in them being the
default - I hope. This is the point of my last commit in the repository
- the one that pushes the _POSIX_C_SOURCE definition into the top-level
Makefile in the spiped distribution. Of course, if you do not like it,
feel free to take the last-but-one commit from the repository and simply
ignore the Makefile bit of the 03-warnings patch attached here.
Post by Colin Percival3. I'll add an #ifdef #undef asprintf to my code, so in a future release
that will no longer be needed. (I have no plans for future releases at
this time, but odds are that at some point one will happen.)
Thanks!
Post by Colin Percival4. I'm happy with replacing cp/strip/chmod/mv with install -- I would have
used install myself except that it's not guaranteed to exist on POSIX.
Yep, I completely understand. I have some ideas about checking for that
at build/install time, but I'll have to think about it some more
(hopefully less than three months this time).
Post by Colin PercivalFinally, can I convince one of you to contribute man pages back under the
two-clause BSD license so I can include them in a future release?
Many thanks to Andreas for actually taking the time to do that! I have
included his manual pages in my Debian package, too - after taking the
liberty of once again converting them to yet another representation
format. In my Debian package, they use the mdoc set of macros instead
of the man ones - IMHO this is 1. a bit more readable, 2. a bit closer
to the BSD origins of spiped itself :)
Once again, thanks to both of you for your work and your patience with
me!
G'luck,
Peter
--
Peter Pentchev ***@ringlet.net ***@FreeBSD.org ***@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
I am the thought you are now thinking.