On Sun, Jun 24, 2012 at 11:29:56AM +0100, Lars Wirzenius wrote:
> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> > believe was introduced by Autoconf
>
> I don't know the history of CPPFLAGS. It's possible it
On 27/06/12 14:20, Ben Hutchings wrote:
> On Wed, 2012-06-27 at 14:09 +0300, Serge wrote:
>> 2012/6/25 Ben Hutchings wrote:
>>
BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
and they use it in CFLAGS/CXXFLAGS.
>>>
>>> Presumably as a workaround for build systems that
On Wed, 2012-06-27 at 14:09 +0300, Serge wrote:
> 2012/6/25 Ben Hutchings wrote:
>
> >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
> >> and they use it in CFLAGS/CXXFLAGS.
> >
> > Presumably as a workaround for build systems that do not respect
> > CPPFLAGS.
>
> I actual
2012/6/25 Ben Hutchings wrote:
>> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
>> and they use it in CFLAGS/CXXFLAGS.
>
> Presumably as a workaround for build systems that do not respect
> CPPFLAGS.
I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess
* Ben Hutchings [120625 19:21]:
> GNU make's implicit rules use CPPFLAGS. If other build systems or
> overriden rules don't use it, it's a bug. This can of course be
> worked around in debian/rules.
I'd not call it a bug. It's just some stranger behavior. Not more strange
than not using make bu
On Mon, Jun 25, 2012 at 06:55:53PM +0300, Serge wrote:
> 2012/6/24 Guillem Jover wrote:
>
> >> Why? Just to have it autotools-compatible? If I was writing a custom
> >> build system I would be thinking about using -Wp option, since that's
> >> exactly why it's there for — to pass some options to t
2012/6/24 Guillem Jover wrote:
>> Why? Just to have it autotools-compatible? If I was writing a custom
>> build system I would be thinking about using -Wp option, since that's
>> exactly why it's there for — to pass some options to the preprocessor
>> (or, being honest, I would ignore CPPFLAGS unl
* Russ Allbery [120624 23:13]:
> When integrating with a build system that uses only one variable for
> compilation flags, just pass the concatenation of CFLAGS and CPPFLAGS into
> it. This is trivially done in debian/rules without modifying the upstream
> source.
Build systems not doing CPPFLAG
"Bernhard R. Link" writes:
> * Lars Wirzenius [120624 12:30]:
>> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
>>> CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
>>> believe was introduced by Autoconf
>> I don't know the history of CPPFLAGS. It's possible i
* Lars Wirzenius [120624 12:30]:
> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> > believe was introduced by Autoconf
>
> I don't know the history of CPPFLAGS. It's possible it was introduced by
> Autoconf.
On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> believe was introduced by Autoconf
I don't know the history of CPPFLAGS. It's possible it was introduced by
Autoconf. However, it is now embedded into the implicit
On Sun, 2012-06-24 at 11:07:05 +0300, Serge wrote:
> 2012/6/24 Russ Allbery wrote:
> >> If you do, then... How should they do that? I.e. if I specify:
> >> CPPFLAGS="blablabla hehehe hohoho"
> >> How should build system run gcc? Like that?
> >> gcc blablabla hehehe hohoho -c -o test.o test.c
>
2012/6/24 Russ Allbery wrote:
>> If you do, then... How should they do that? I.e. if I specify:
>> CPPFLAGS="blablabla hehehe hohoho"
>> How should build system run gcc? Like that?
>> gcc blablabla hehehe hohoho -c -o test.o test.c
>
> Yes.
Why? Just to have it autotools-compatible? If I was
Serge writes:
> Or you mean that they should run `gcc`/`g++` with CPPFLAGS?
Yes.
> If you do, then... How should they do that? I.e. if I specify:
> CPPFLAGS="blablabla hehehe hohoho"
> How should build system run gcc? Like that?
> gcc blablabla hehehe hohoho -c test.o test.c
Yes.
> Is the
2012/6/23 Adam Borowski wrote:
>> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST ignore
>> the CPPFLAGS, right?
>
> They SH
Serge writes:
> 2012/6/23 Andrey Rahmatullin wrote:
>> Do you say that cpp(1) is not used in the build process of C and C++
>> software?
> Yes, unless you actually call `cpp` directly by your build scripts somewhy.
> Gcc uses internal preprocessor by default.
Same thing in different packaging.
2012/6/23 Andrey Rahmatullin wrote:
>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST
>> ignore the CPPFLAGS, right?
>
> Do you say that cpp(1) is not used in the build process of C and C++
> software?
On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> 2012/6/19 José Luis Segura Lucas wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds
On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (C
2012/6/19 José Luis Segura Lucas wrote:
> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to define "export
> DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS)
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote:
> repository but not still in a numbered version, so, I tried to use the
> latest known version and add a ~TIMESTAMPgit... to the minor version
> number, but debuild warns me about the version 0.1.0~2012..git-1 is
> less th
On Tue, Jun 19, 2012 at 05:04:46PM +0200, José Luis Segura Lucas wrote:
> > I see several solutions there, and the hardening-wrapper one is in my
> > opinion the worst one: it adds a build dependency and it uses own set of
> > configuration variables, not compatible with dpkg-buildflags ones.
> Yes
El 19/06/12 16:56, Andrey Rahmatullin escribió:
> I see several solutions there, and the hardening-wrapper one is in my
> opinion the worst one: it adds a build dependency and it uses own set of
> configuration variables, not compatible with dpkg-buildflags ones.
Yes, it adds a build-dependency...
On Tue, Jun 19, 2012 at 04:42:33PM +0200, José Luis Segura Lucas wrote:
> > Why do you need hardening-wrapper? You should use flags set by
> > dpkg-buildflags.
> Because that
> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to
El 19/06/12 16:10, Andrey Rahmatullin escribió:
> Why do you need hardening-wrapper? You should use flags set by
> dpkg-buildflags.
Because that
(http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
referred by lintian-info too. Using it I only need to define "export
DEB_BUILD_HARDENIN
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote:
> I have read the output of lintian-info -t about
> hardening-no-fortify-functions, and it helps a lot. The software uses
> Cmake as build tool, and the "hardening-wrapper" solution solved some
> lintian warnings, but not the l
Hi!
I'm intending to package a new software for Debian [1]. I just completed
most of the package work and have a lintian-error free package, but I
still have a warning that is driving me crazy.
I have read the output of lintian-info -t about
hardening-no-fortify-functions, and it helps a lot. The
27 matches
Mail list logo
