[perl #38124] [TODO] build - header file detection w/o perl5

[Joshua Hoblitt]

auto::headers uses the Config module to detect installed header files.
It's ok to get default values and the arch name from Config but it's not
OK to depend on it for probing the system as the Configure code will
liked be compiled down to PIR someday so it can be executed by
miniparrot and systems that don't have perl5 installed.

We've long recognized that we will eventually have to jettison our
reliance on Perl 5's Config module, not just for header detection but
for all of our configuration probes. But that's a post-1.0 project.

Are we closing all bugs for things that aren't going to be part of a 1.0
release?

-J

--

[Will Coleda]

Post by Joshua Hoblitt

auto::headers uses the Config module to detect installed header files.
It's ok to get default values and the arch name from Config but it's not
OK to depend on it for probing the system as the Configure code will
liked be compiled down to PIR someday so it can be executed by
miniparrot and systems that don't have perl5 installed.

We've long recognized that we will eventually have to jettison our
reliance on Perl 5's Config module, not just for header detection but
for all of our configuration probes. But that's a post-1.0 project.

Are we closing all bugs for things that aren't going to be part of a 1.0
release?
-J
--

We shouldn't be closing things solely for that reason, no.

[Kjstol]

--0016e6d27ed115527f04626b457c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Post by Will Coleda

Post by Joshua Hoblitt

auto::headers uses the Config module to detect installed header files.
It's ok to get default values and the arch name from Config but it's

not

Post by Joshua Hoblitt

OK to depend on it for probing the system as the Configure code will
liked be compiled down to PIR someday so it can be executed by
miniparrot and systems that don't have perl5 installed.

We've long recognized that we will eventually have to jettison our
reliance on Perl 5's Config module, not just for header detection but
for all of our configuration probes. But that's a post-1.0 project.

Are we closing all bugs for things that aren't going to be part of a 1.0
release?
-J
--

We shouldn't be closing things solely for that reason, no.
--
Will "Coke" Coleda

Maybe it'd be good to add these tickets to trac, planned for a certain
release. That way, their status and future plans are documented better, and
it will prevent future confusion as activity of the project members will
vary over time (new people joining, others disappearing, etc.)

just a thought.
kjs