Bob Atkins <[EMAIL PROTECTED]> added the comment:
Martin,
Martin v. Löwis wrote:
It does not when link stage specific options are required that are not
valid for compilation stages.
My mistake. I was thinking of another package - you can scratch that
comment.
There is no hard and fast rule that specifying the CFLAGS or other
configure variables have to override /_*all*_/ of the compile flags that
a developer chooses to use in their build process. Most open source
packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the
compile and link flags and not completely override them. My patch
follows the same philosophy that I have seen in the majority of other
open source packages.
On the contrary - it does /_*not*_/ make it more complex and it
/_*does*_/ provide a solution to a number of compile and link failures
that have been reported over and over again. When I first posted this
bug I read through the various forums and bug reports and I noticed
quite a bit of complaining regarding this issue and I acknowledged that
by noting in my report that what I was opening a bug report on what was
clearly a sore subject within the Python community. To be specific the
complaints were regarding the symptoms (unusual compile and link
problems) related to this issue, not the specific cause of the problem
which is why I filed the bug as I did.
The patch that I submitted will allow a build of Python to be performed
the /_exact_/ same way it is today without any modifications to CFLAGS
or LDFLAGS, etc. Those of us that /need/ to use these variables will be
able to modify the build options to the configure script as necessary
/_*without*_/ any complexity and without losing 'important' compile
options that are currently generated by configure. All of your
suggestions to use the CC variable in lieu of using the more appropriate
CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard
approach you are claiming you want top avoid.
Again, I don't see what your concerns are. My patch is a completely
non-affecting change to the way Python is built today /_*but*_/ it does
add the necessary fixes so that those that require specific compile and
link options can specify them to the configure script.
In addition, while you are fixing the build/compile options, I noticed
that you are missing the -fPIC compile option. Without it you can't link
shared libraries and the build fails. You should probably be including
-fPIC as a standard compile option so it is not required to be passed
into the build via the configure script.
---
Bob
Added file: http://bugs.python.org/file10033/unnamed
_____________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1628484>
_____________________________________
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Martin,<br>
<br>
Martin v. Löwis wrote:
<blockquote cite="[EMAIL PROTECTED]" type="cite">
<pre wrap="">Martin v. Löwis <a class="moz-txt-link-rfc2396E"
href="mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]></a> added the comment:
</pre>
<blockquote type="cite">
<pre wrap="">Your suggestion for using the CC variable to fix the problem
that I
reported won't work - I already tried it and based on what others are
reporting, you are beating a dead horse. Believe me I would rather not
modify anyone's code in order to build something. The problem is that
the CC variable doesn't fix the link stages
</pre>
</blockquote>
<pre wrap=""><!---->
Why is that? It should work fine.
</pre>
</blockquote>
It does not when link stage specific options are required that are not
valid for compilation stages.<br>
<blockquote cite="[EMAIL PROTECTED]" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">and overall your autconf
build is broken particularly as it relates to flowing variables down to
sub builds.
</pre>
</blockquote>
<pre wrap=""><!---->
This I don't understand. What is a sub build?
</pre>
</blockquote>
My mistake. I was thinking of another package - you can scratch that
comment.<br>
<blockquote cite="[EMAIL PROTECTED]" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I don't know why you are resisting this change. I took the
time to
report the bug, proposed a fix /_*and*_/ contributed the patch that
would make the Python build process more standard relative to the vast
majority of open source packages that use autoconf.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't think that's the case. In autoconf, if you specify CFLAGS,
you expect that this overrides, not adds to, anything configure
computes on its own. This patch does not do that, i.e. it doesn't
allow you to override the settings that configure computes.
</pre>
</blockquote>
There is no hard and fast rule that specifying the CFLAGS or other
configure variables have to override <i><u><b>all</b></u></i> of the
compile flags that a developer chooses to use in their build process.
Most open source packages use the configure CFLAGS, LDFLAGS, etc,
variables to add to the compile and link flags and not completely
override them. My patch follows the same philosophy that I have seen in
the majority of other open source packages.<br>
<blockquote cite="[EMAIL PROTECTED]" type="cite">
<pre wrap="">
I'm concerned that the patch merely makes the entire setup more
complex, rather than solving an actual technical problem. That's
why I'm resisting to accept it.
</pre>
</blockquote>
On the contrary - it does <i><u><b>not</b></u></i> make it more
complex and it <i><u><b>does</b></u></i> provide a solution to a
number of compile and link failures that have been reported over and
over again. When I first posted this bug I read through the various
forums and bug reports and I noticed quite a bit of complaining
regarding this issue and I acknowledged that by noting in my report
that what I was opening a bug report on what was clearly a sore subject
within the Python community. To be specific the complaints were
regarding the symptoms (unusual compile and link problems) related to
this issue, not the specific cause of the problem which is why I filed
the bug as I did.<br>
<br>
The patch that I submitted will allow a build of Python to be performed
the <i><u>exact</u></i> same way it is today without any modifications
to CFLAGS or LDFLAGS, etc. Those of us that <i>need</i> to use these
variables will be able to modify the build options to the configure
script as necessary <i><u><b>without</b></u></i> any complexity and
without losing 'important' compile options that are currently generated
by configure. All of your suggestions to use the CC variable in lieu of
using the more appropriate CFLAGS, LDFLAGS, etc., introduce the very
complexity and non-standard approach you are claiming you want top
avoid.<br>
<br>
Again, I don't see what your concerns are. My patch is a completely
non-affecting change to the way Python is built today <i><u><b>but</b></u></i>
it does add the necessary fixes so that those that require specific
compile and link options can specify them to the configure script.<br>
<br>
In addition, while you are fixing the build/compile options, I noticed
that you are missing the -fPIC compile option. Without it you can't
link shared libraries and the build fails. You should probably be
including -fPIC as a standard compile option so it is not required to
be passed into the build via the configure script.<br>
<br>
---<br>
Bob
<div class="moz-signature">
<p>Â </p>
</div>
</body>
</html>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
