In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016
16:32:35 +0100, Corinna Vinschen <vinsc...@redhat.com> said:
vinschen> On Jan 17 14:56, Richard Levitte wrote:
vinschen> > In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016
14:16:04 +0100, Kurt Roeckx <k...@roeckx.be> said:
vinschen> >
vinschen> > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte
wrote:
vinschen> > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I
suggest you
vinschen> > kurt> > have a look at Configurations/10-main.conf, you might notice
vinschen> > kurt> > configuration items like debug_cflags, release_cflags,
debug_lflags
vinschen> > kurt> > and release_lflags. If you have a look at my
refactor-build branch,
vinschen> > kurt> > you will see a fairly thorough Configurations/README. If
you look the
vinschen> > kurt> > commit titled "Refactor config - move templates docs asm
templates to
vinschen> > kurt> > Configurations", you'll find the documentation that's
applicable to
vinschen> > kurt> > what Configure in the master branch supports... later
editions are
vinschen> > kurt> > currently only supported in my branch.
vinschen> > kurt>
vinschen> > kurt> In Debian we have a system that where you can override things
like
vinschen> > kurt> the CFLAGS, and I wonder how easy it will be to integrate that
vinschen> > kurt> with your new system.
vinschen> > kurt> [...]
vinschen> > kurt> Is there an easy way to I can override the flags with
vinschen> > kurt> dpkg-buildflags?
vinschen> >
vinschen> > I see where you're going with this.
vinschen> >
vinschen> > As it is right now, there is no way to affect Configure via the
vinschen> > environment, except for the names of certain commands. Personally,
vinschen> > I'd say that using those should be done carefully. I have no plans
to
vinschen> > expand on the use of environment variables...
vinschen> >
vinschen> > However, there is always the possibility to quickly write up a small
vinschen> > config target for yourself in Configurations, and have them inherit
vinschen> > the items for an already existing target. For example:
vinschen> >
vinschen> > cflags=` ... dpkg-buildflags --get CFLAGS`; \
vinschen> > cat <<EOF > Configurations/01-debian-tmp.conf
vinschen> > %targets = (
vinschen> > "debian-linux-x86_64" => {
vinschen> > inherit_from => [ "linux-x86_64" ],
vinschen> > cflags => "$cflags",
vinschen> > }
vinschen> > );
vinschen> > 1;
vinschen> > EOF
vinschen> >
vinschen> > If you want to just append or prepend your flags, you do this with
the
vinschen> > cflags item:
vinschen> >
vinschen> > cflags => sub { join(" ", $@, "$cflags"); },
vinschen> >
vinschen> > In my refactor-build branch, I've added some lazy functions to do
the
vinschen> > same:
vinschen> >
vinschen> > cflags => add("$cflags"),
vinschen> >
vinschen> > or
vinschen> >
vinschen> > cflags => add_before("$cflags"), # to prepend
vinschen> >
vinschen> > Did that help?
vinschen>
vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from
the
vinschen> environment, you require all distros to patch the OpenSSL package to
fit
vinschen> their needs in terms of the build flags.
Actually, I forgot another possibility, to just pass them on the
Configure / config command line, like so:
./config -ggdb -O2 -pipe -Wimplicit-function-declaration \
-fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \
-fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1
Basically, anything start with a dash or plus that Configure doesn't
recognise as its own, it will pass down:
* if it starts with -l. -L or -Wl, into EX_LIBS, which is
essentially flags to the linker.
* otherwise, into CFLAG / CFLAGS.
Can't believe I forgot to mention that, considering I use it all the
time...
vinschen> Why is that necessary? It's no problem at all with autotool
vinschen> or cmake-based configurations, and it's really *needed* by
vinschen> distros.
Before we all go off on a tangent, I'd like to point out that I'm only
stating how it works as it is right now. We're not strangers to
making changes, even though carefully most of the times ;-)
vinschen> CFLAGS+=$(OPENSSL_CFLAGS)
+= is a GNU make extension, and therefore a no can do. We need to
stay with generic make.
vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS[...etc...]
vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)"
vinschen>
vinschen> and the package build system has to set $BUILD_CFLAGS. That would
vinschen> be sufficient as well.
If my info about the Configure command line above wasn't good enough,
I do have a fairly simple idea on how to allow for using environment
variables to expand the diverse flag items, more or less directly into
the target structure.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
