[issue28584] ICC compiler check is too permissive

2022-03-22 Thread Ben Boeckel


Change by Ben Boeckel :


--
nosy: +mathstuf

___
Python tracker 
<https://bugs.python.org/issue28584>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44832] Compiler detection is not strict enough

2021-08-04 Thread Ben Boeckel


New submission from Ben Boeckel :

Generally, the `configure.ac` script tries to detect compilers based on the 
path to the compiler. This is mostly fine, but trips up when using `mpicc` as 
the compiler. Even if the underlying compiler is `gcc`, this gets detected as 
`icc` in various situations.

The best solution is to do some compiler introspection like CMake does to 
determine what the compiler actually is, but I'm not familiar with the patterns 
used or available tools in autotools for such things.

--
components: Build
messages: 398920
nosy: mathstuf
priority: normal
severity: normal
status: open
title: Compiler detection is not strict enough
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44832>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42228] Activate.ps1 clears PYTHONHOME

2020-11-02 Thread Ben Boeckel


Ben Boeckel  added the comment:

We build our own applications which run Python interpreters internally, so the 
auto-discovery won't work. It also doesn't seem to work for venvs either since 
the venv's `python.exe` is under `Scripts` which makes it not able to find 
things either on its own.

I've worked around it so far by just ignoring `Activate.ps1` completely and 
setting up PATH, PYTHONHOME, and PYTHONPATH instead, but this tells me that 
`Activate.ps1` probably needs some consideration for other use cases. The 
layout certainly seems wrong for auto-discovery at least.

--

___
Python tracker 
<https://bugs.python.org/issue42228>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42228] Activate.ps1 clears PYTHONHOME

2020-11-01 Thread Ben Boeckel


New submission from Ben Boeckel :

On Windows, we are extracting a tarball of a Python installation for CI (to 
avoid needing to juggle umpteen Python installs on umpteen machines). This 
requires `PYTHONHOME` to be set to use properly since there is no registry 
entry for the "installation". However, `Activate.ps1` clears `PYTHONHOME` 
unconditionally. Is there something else we can do to properly integrate with 
it or should there be an option to say "no, I need `PYTHONHOME` for the stdlib 
to work"?

I don't know how relevant this is to other platforms at the moment as other 
mechanisms are sufficient there (Xcode's Python3.framework in the SDK and Linux 
system packages).

--
components: Windows
messages: 380125
nosy: mathstuf, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Activate.ps1 clears PYTHONHOME
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue42228>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38728] Update PC/pyconfig.h to support disabling auto linking

2020-05-12 Thread Ben Boeckel


Ben Boeckel  added the comment:

> Presumably you looked around for ideas before figuring out the issue

Usually when "could not find foo.lib" popping up without any mention of 
"foo.lib" on the link line points directly to these "autolinking" "features" 
being the culprit. It's just something I've learned through experience. If 
there's an FAQ of common problems when building C extensions, it belongs there.

While this functionality sounds nice in principle, it only really works if 
something also adds the directory to *look* for the library to the link line as 
well. But if you can get *that* to the link line, you may as well just add the 
".lib" to the link line directly and not send the linker on a wild goose chase 
based on a header. In addition, nothing ties "find python.lib" to the one that 
actually goes with the header that's telling it to be found either, so you can 
get the wrong one too (probably not so much an issue for Python now that ABI 
flags are gone, but it's still a thing).

Due to these behaviors and the lack of a link directory pragma (not that you 
could write a relocatable one in C preprocessor anyways), I find `#pragma 
comment(lib)` to just be a misfeature more than anything.

--

___
Python tracker 
<https://bugs.python.org/issue38728>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37588] Py_DEPRECATED and unavoidable warnings

2020-03-10 Thread Ben Boeckel


Ben Boeckel  added the comment:

I believe this to be a clang bug. I've filed an issue with upstream here: 
https://bugs.llvm.org/show_bug.cgi?id=45170

--
nosy: +mathstuf

___
Python tracker 
<https://bugs.python.org/issue37588>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39624] Trace greedy replaces $prefix and $exec_prefix

2020-02-17 Thread Ben Boeckel


Ben Boeckel  added the comment:

> The paths are not user provided: they are hardcoded paths from the sysconfig 
> module:

No, those paths are the *replacement* values, not the input. From the trace 
docs:

>   trace.py -c -f counts --ignore-dir '$prefix' spam.py eggs

This is the string where `$prefix` is replaced with the value retrieved from 
`sysconfig`.

--

___
Python tracker 
<https://bugs.python.org/issue39624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39624] Trace greedy replaces $prefix and $exec_prefix

2020-02-13 Thread Ben Boeckel


Ben Boeckel  added the comment:

`\b` is a bit too loose. That example should *not* have it replaced because it 
is not a full path component.

(Granted, any of these conflicting paths are "dumb" in general; I'm fine with 
just leaving this as a low priority, but if it does get modified, it should 
actually get fixed.)

--

___
Python tracker 
<https://bugs.python.org/issue39624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39624] Trace greedy replaces $prefix and $exec_prefix

2020-02-13 Thread Ben Boeckel


New submission from Ben Boeckel :

Previously reported as a sidenote in Issue21016.

The `--ignore-dir` option in trace.py replaces `$prefix` and `$exec_prefix` 
*anywhere* in the path when it really should just replace it in the start of 
the path and if it is followed by nothing or a path separator (that is, it is a 
path component). I suspect that there's always a separator though.

--
components: Library (Lib)
messages: 361949
nosy: mathstuf, vstinner
priority: normal
severity: normal
status: open
title: Trace greedy replaces $prefix and $exec_prefix

___
Python tracker 
<https://bugs.python.org/issue39624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21016] trace: $prefix and $exec_prefix improperly replaced on Fedora

2020-02-12 Thread Ben Boeckel


Ben Boeckel  added the comment:

Thanks!

Should I file a new issue for the other (less urgent) problem mentioned at the 
bottom or is it not really worth fixing?

> It also erroneously replaces things like '$prefixpath'. It should probably do 
> split the path on the path separators and only replace components that are 
> equal to $prefix or $exec_prefix (so that the '$' can be escaped for 
> directories named as such literally, but that would require a pass to parse 
> the escapes).

--

___
Python tracker 
<https://bugs.python.org/issue21016>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39066] Expose SOABI setting in the header

2019-12-16 Thread Ben Boeckel


Ben Boeckel  added the comment:

Ah, that does look like it is suitable (since it is a shell script). I assume 
it is a batch script on Windows (though I feel cross-compilation is far rarer 
there). Thanks.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39066>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39066] Expose SOABI setting in the header

2019-12-16 Thread Ben Boeckel


New submission from Ben Boeckel :

Currently, the SOABI suffix is only available by running the Python interpreter 
to ask `sysconfig` about the setting. This complicates cross compilation 
because the target platform's Python may not be runnable on the build platform. 
Exposing this in the header would allow for build processes to know what suffix 
to add to modules without having to run the interpreter.

--
components: C API
messages: 358489
nosy: mathstuf
priority: normal
severity: normal
status: open
title: Expose SOABI setting in the header
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue39066>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38728] Update PC/pyconfig.h to support disabling auto linking

2019-11-14 Thread Ben Boeckel


Change by Ben Boeckel :


--
nosy: +mathstuf

___
Python tracker 
<https://bugs.python.org/issue38728>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21016] trace: $prefix and $exec_prefix improperly replaced on Fedora

2014-03-21 Thread Ben Boeckel

New submission from Ben Boeckel:

In the --ignore-dir handling of trace.py, the following is done:

s = s.replace($prefix,
  os.path.join(sys.base_prefix, lib,
   python + sys.version[:3]))
s = s.replace($exec_prefix,
  os.path.join(sys.base_exec_prefix, lib,
   python + sys.version[:3]))

This does not do what is expected on 64-bit Fedora and newer Debian since the 
proper directory is /usr/lib64/python2.7 or /usr/lib/$triple/python2.7. Just 
the libsuffix can't be changed either since Fedora also has /usr/lib/python2.7 
for arch-independent modules. It'd be nice if $prefix were replaced with the 
following directories from sysconfig.get_paths(): platstdlib, platlib, purelib, 
and stdlib.

It also erroneously replaces things like '$prefixpath'. It should probably do 
split the path on the path separators and only replace components that are 
equal to $prefix or $exec_prefix (so that the '$' can be escaped for 
directories named as such literally, but that would require a pass to parse the 
escapes).

--
components: Library (Lib)
messages: 214435
nosy: mathstuf
priority: normal
severity: normal
status: open
title: trace: $prefix and $exec_prefix improperly replaced on Fedora
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21016
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com