This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: _locale library patch
Type: Stage:
Components: Distutils Versions:
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: jlt63 Nosy List: jlt63, loewis
Priority: normal Keywords: patch

Created on 2002-07-30 13:58 by jlt63, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
setup.py.diff jlt63, 2002-07-30 13:58
Messages (7)
msg40729 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2002-07-30 13:58
This patch enables setup.py to find gettext routines
when they are located in libintl instead of libc.
Although I developed this patch for Cygwin, I hope
that it can be easily updated to support other
platforms (if necessary). I tested this patch
under Cygwin and Red Hat Linux 7.1.
msg40730 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-04 08:37
Logged In: YES 
user_id=21627

I would really prefer if such problems where solved in an
autoconf-style approach: 
- is libintl.h present (you may ask pyconfig.h for that)
  - if so, is gettext provided by the C library
  - if not, is it provided by -lintl
     - if yes, add -lintl
     - if no, print an error message and continue
msg40731 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2002-08-09 18:04
Logged In: YES 
user_id=86216

I presume that you mean to use an
autoconf-style approach *in* setup.py.
Is this assumption correct?

If so, then I know how to search for
libintl.h via find_file(). Unfortunately,
I do not know how to check that a
function (e.g., getext()) is in a library
(i.e., libc.a). Any suggestions?
msg40732 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-09 23:49
Logged In: YES 
user_id=21627

Yes, that's what I meant. It eventually results in distutils
getting some of the capabilities of autoconf.

I agree this is a major undertaking, but one that I think
needs to progress over time, in small steps.

For the current problem, it might be useful to emulate
AC_TRY_LINK: generate a small program, and see whether the
compiler manages to link it.

You probably need to allow for result-caching as well; I
recommend to put the cache file into build/temp.<system>.

This may all sound very ad-hoc, but I think it can be made
to work with reasonable effort. We probably need to present
any results to distutils-sig before committing them.
msg40733 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2002-08-12 11:53
Logged In: YES 
user_id=86216

I'm a strong proponent of doing the right thing.
The unfortunate reality is that I'm way
overcommitted right now. Hence, I don't have the
spare cycles to figure out the best way to
accomplish this "major undertaking" (to quote
you). Additionally, one of the distutils
developers could do a better job with much less
effort than I could.

Please reconsider my original patch. I'm willing
to change it (in the future) to be more
autoconf-like if someone else is willing to do the
underlying work.
msg40734 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-14 09:21
Logged In: YES 
user_id=21627

Ok, I'll accept the patch - please apply it.

As for distutils developers - there are none left, so unless
interested users develop it, it is stuck right where it is now.
msg40735 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2002-08-14 11:17
Logged In: YES 
user_id=86216

> Ok, I'll accept the patch - please apply it.

Committed as setup.py 1.107.

> As for distutils developers - there are none
> left, so unless interested users develop it, it
> is stuck right where it is now.

Ouch! Given that the Python build is dependent on
distutils this is especially painful...
History
Date User Action Args
2022-04-10 16:05:32adminsetgithub: 36950
2002-07-30 13:58:21jlt63create