Unacceptable use of Config::AutoConf for compiler-detection.

[ribasushi]

Config::AutoConf is widely regarded by the toolchain as an "exercise of overengineering". Thus there is high motivation to limit its proliferation, which in turn makes the use of C::AC in "high upriver" projects very undesirable.

Given the mandate of "avoid whenever possible", using C::AC exclusively for compiler detection is definitively unacceptable. This ticket's sole purpose is a formal request to @rehsack to remove C::AC from the configure_requires of List::MoreUtils until a widely accepted need for C::AC arises.

[rehsack]

This is a formal reject of the request to remove Config::AutoConf as compiler detection, because of no sane reason. I completely disagree to the "exercise of overengineering" - but I don't do the discussion from #9 again.

My technical reasons are: there is no sane compiler test and the upcoming ExtUtils::HasCompiler is very untested and might be a solution when enough effort will be put into it. As a persona non grata I currently see no benefit in starting a concurrency thread criticize EU::HC.

Personal hint - stop the affronts and search for a way to step forward in a cooperative manner. Trying to enforce will result in complete separation (I already told you that).

[ribasushi]

This is a formal reject of the request to remove Config::AutoConf as compiler detection

Nod. This is sufficient written record for others to justify "we need to switch away" arguments elsewhere.

I currently see no benefit in starting a concurrency thread criticize EU::HC.

Let me stress this again - given the current mood, C::AC is extremely unlikely to become the dominant configure-time compiler detection mechanism CPAN-wide (you are currently the sole advocate of this, and there is no viable mechanism to get more distributions to start using it). Therefore I urge you to log as early as possible any and all complaints you have about EU::HC. If nothing else this would be of direct benefit to your niche concern of cross-compilation.

Personal hint ...

I urge you to stop making it personal. None of the recent discussions are about you. They are fully and exclusively about grossly suboptimal decisions. You just happened to be the one who carried these decisions out.

[rehsack]

This is a formal reject of the request to remove Config::AutoConf as compiler detection

Nod. This is sufficient written record for others to justify "we need to switch away" arguments elsewhere.

If you need a full control over all your dependencies - please do. Of course this is the separation I referred to, which will have significant influence. I strongly recommend you urge them to move away from all my distributions.

This marks lot's of comments in #9 as a lie ("it's only about user-side test generation") and I'm glad that you admit it.

I currently see no benefit in starting a concurrency thread criticize EU::HC.

Let me stress this again - given the current mood, C::AC is extremely unlikely to become the dominant configure-time compiler detection mechanism CPAN-wide (you are currently the sole advocate of this, and there is no viable mechanism to get more distributions to start using it). Therefore I urge you to log as early as possible any and all complaints you have about EU::HC. If nothing else this would be of direct benefit to your niche concern of cross-compilation.

As long as you call every of my use-cases as a niche and strength your cited niches as the main use, we will never agree in any point. And no - I don't refer to cross-compilation only. And I don't intend to force C::AC being the dominant configure-time compiler detection mechanism. When it delivers examples to find a better one, I'm fine to switch after the better one is proven over time (this will take years - and I don't intend to rush a change for change for change in this distribution). Currently there is nothing better - and as long the situation doesn't change, I use C::AC.

Again - I don't have the energy anymore to do discussions like this, #9 and all the earlier ones. No more energy to fight for time to discuss requirements and urge people to meetings with arguable value. The world outside of perl realized the requirement of a probe system like autoconf - as long as we don't have similar in perl and no people who care, but code and publish - as that long I refuse being Don Quichote. I'm sick for "works for me (tm)" solutions with no interest of big picture.

Personal hint ... I urge you to stop making it personal. None of the recent discussions are about you. They are fully and exclusively about grossly suboptimal decisions. You just happened to be the one who carried these decisions out.

Trying to enforce something without technical reason in a technical world is insane and the way how you do it is personal. However - when you urge your dependencies moving away - maybe the calm returns and serious improving takes place. Or noone else cares and everything keeps as it is.

[ribasushi]

This marks lot's of comments in https://github.com/perl5-utils/List-MoreUtils/pull/9 as a lie ("it's only about user-side test generation")

Err... https://github.com/perl5-utils/List-MoreUtils/pull/9 was (at least to me) chiefly about user-side test generation. That issue was mostly addressed by https://github.com/perl5-utils/List-MoreUtils/commit/91f51eae, which I acknowledged right here: https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-100459804.

The current ticket is about the second issue that turned LMU into a highly problematic dist, which I opened as per https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-100223044

And I don't intend to force C::AC being the dominant configure-time compiler detection mechanism.

This is excellent news! Please reconsider giving technical feedback on EU::HC - I assure you that @leont and the rest of the PTG will greatly appreciate it.

[rehsack]

The current ticket is about the second issue that turned LMU into a highly problematic dist, which I opened as per #9 (comment)

Because it doesn't has been solved with the approach in #9

While I had nearly no opinion about user-side test generation and happily fix the issue - even if no one explained the problems in details, neither here.

So when all you call "highly problematic" is the usage of a slightly over-engineered solution (for no further explanation, showing real problems and showing where maintainers didn't care for real problems), then all I can do is shrug.

This is sufficient written record for others to justify "we need to switch away" arguments elsewhere Please reconsider giving technical feedback on EU::HC - I assure you that @leont and the rest of the PTG will greatly appreciate it.

As long as I cannot distinguish between "we" and PTG - I don't see why I should. I consider "we" as those who commented in #9 and commented in irc and on that base I don't see less options for cooperation.

Given you're speaking for the gang, and offering this way or highway - I choose highway and wish you luck.

[shadowcat-mst]

So when all you call "highly problematic" is the usage of a slightly over-engineered solution (for no further explanation, showing real problems and showing where maintainers didn't care for real problems)

I feel like when using a complicated solution for a simple problem in a heavily depended upon dist, the burden of proof that that makes sense is upon justifying the complexity.

i.e. show us why this is necessary, and show us how you've already tested this solution in the wild.

As long as I cannot distinguish between "we" and PTG - I don't see why I should.

This attitude is what is pushing multiple members of PTG towards believing you will make switching away the only option. I really really don't want to become part of that 'we' but you seem determined to force me to be.

Given you're speaking for the gang, and offering this way or highway

He isn't, necessarily, but at this point I think it's fairly well agreed that -you- are making that offer to everybody else.

I tried to illustrate this in #9 with aristotle's assistance to avoid translation problems, but my attempts to be polite and conciliatory failed. If you are now finding that you're largely talking to ribasushi, it's not because he necessarily speaks for everybody, it's because you've been sufficiently stubborn that other people are starting to think that trying to have a reasoned discussion with you is a waste of their time and emotional energy.

[karenetheridge]

it's because you've been sufficiently stubborn that other people are starting to think that trying to have a reasoned discussion with you is a waste of their time and emotional energy.

raises hand

[kentfredric]

Try to see it from our perspective:

• You have a module you use
• Lots of people use this module
• Module is mostly straight forward and simple complexity wise
• Essentially a collection of pure functions, no confusing architecture requirements
• Functions do very rudimentary things with simple perl primitives
• Module has been shipped and used for 5 years without problem
• New Author comes along
• Module now has complexity in its build process an order of magnitude more complex than the functions it ships
• Module now as complexity that out strips most other modules at similar levels of utility by an order of magnitude ( Yes, XS considered )

You get this far and this is already "Uh, scary" stuff. We refer to that sort of thing colloquially as "code smell".

As an analogy, the degree of changing here is like having your local convenience store install backscatter gear and bomb dogs at the front door and establish a 20 meter perimeter of armed soldiers aimed at you.

Its scary and you say "Uh, is this really warranted? its just a convenience store".

And the convenience store retorts, "Prove it isn't".

[kentfredric]

I strongly recommend you urge them to move away from all my distributions.

^ Fwiw, I also have distributions which I have urged people to move away from.

But the reasons are different: Those distributions of mine are inferior with design complications that can't be resolved and one is likely to be throwing themselves under a bus by using them. I aim to fix them as best as possible, but my hands are effectively tied because you can't un-fuck fundamentally flawed design issues.

I usually however try to listen to the CPAN audience, and understand their needs, and try to optimise the stuff I write to suit their needs, and wait for them to approve my approach, and I am quite happy going back to the drawing board several times to implement changes in the right way, before I ship.

As such, a statement of "Move away from my code", regardless of the qualification you may have placed before it, is a kind of statement of hostility towards the whole of CPAN, not merely one person, but all of CPAN.

Thus, a person getting maintainership of modules, and then engaging in maintainership practices under the guise of "if you don't like it, leave", with all due respect, very much does meet the definition of "unacceptable".

[rehsack]

I feel like when using a complicated solution for a simple problem in a heavily depended upon dist, the burden of proof that that makes sense is upon justifying the complexity. i.e. show us why this is necessary, and show us how you've already tested this solution in the wild.

I did in #9 - but you don't even try to understand. I offered a session where I explain all those details - but it wasn't wanted. It's wanted to switch away from the way I chose, regardless of the reasons.

It's quite interesting calling me stubborn who fights for more than 5 years meanwhile for better compiler tooling - and finally giving up because of those threads and the circular arguing ("Show us that it works and is proved. Uh, that smells - I don't want to see more. Take it away unless you convinced us that it works and is proved.").

Yes, I fight for my conviction. But here I give up - move away.

[Leont]

I agree C::AC is not the logical choice for compiler detection, I'm not seeing any advantage over using ExtUtils::CBuilder's have_compiler directly, if only because C::AC is using EU::CB underneath. I do believe we can do a better job of this checking than we're doing this now (for example by checking if the result is loadable), and EU::HC is an attempt at that.

I do think it's the best thing (or even the only thing) we've currently got for various compilation/configuration checks (is this function available, or this header, what is the value of a macro), but I don't think that's really necessary in this case.

[rehsack]

@leont - EU::HC fails havily compared to EU::CB by relying on Config only. On certain environments (I remember around the time of Perl 5.10 where pkgsrc played a lot on IRIX and MIPSpro and AIX using xlc wrapped for gcc compatible calling) when the PATH is limited, some builders use hard coded FQPN for all build tools. Those path's were in a temporary build root and it's gone after the build. Any following access to such $Config{cc} failed heavily (which causes us there to fix Config_heavy.pl on install). However - always prefer $ENV over $Config!

And that's only one thingie ... it doesn't work for the edge cases (what causes me not to implement the loader check in C::AC):

$ grep cross tmp/work/x86_64-linux/perl-native/5.14.3-r0/perl-5.14.3/lib/Config_heavy.pl
usecrosscompile='undef'
$ grep cross  tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/perl/5.14.3-r1/package/usr/lib/perl/5.14.3/Config_heavy.pl
usecrosscompile='undef'
$ file tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/perl/5.14.3-r1/package/usr/bin/perl5.14.3
tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/perl/5.14.3-r1/package/usr/bin/perl5.14.3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xfa932544e2b91f16647c10512bc8ffc7f4cd71f1, stripped

Damn! And even if tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/perl/5.14.3-r1/package/usr/lib/perl/5.14.3/Config_heavy.pl would have usecrosscompile set - you'll never know at the place where it matters (since the configure stage is executed using SDK perl (perl-native) and on the target it's not sane).

I wholehearly agree - Config::AutoConf needs a lot of (attention, bike-shedding, renaming, splitting, ...) until a sane "reduced to the max" compiler test comes out. Do you remember since when I bug you to sit together to discuss the requirement of such checks, how long I wait for EU::CB successor (noted it to https://github.com/ambs/Config-AutoConf/issues/6 as a reminder) to review and comment on, a brainstorming how we deal with the check/prove results to make such an "reduced to the max" check extensible and so on.

C::AC uses similar compile checks as you're EU::HC does - with the difference of the ability fixing https://github.com/ambs/Config-AutoConf/issues/7 without shipping. This is enterprise support!

[rehsack]

@kentfredric - allow me to respond:

You have a module you use Lots of people use this module Module is mostly straight forward and simple complexity wise

Here is the first wrong assumption. In Pure-Perl it might by simple complexity wise - the XS part is far away from being that simple.

Essentially a collection of pure functions, no confusing architecture requirements

Yeah - such pure functions as each_array and natatime and RT#102673 (Summarize of collected wishlist entries).

Functions do very rudimentary things with simple perl primitives

You can do stand-up comedy with that statement :)

Module has been shipped and used for 5 years without problem

Haha. Ticket list speaks a complete different language (bearing in mind the fundamental mistakes happened between hijacked co-maint and I recovered thanks to @dagolden).

New Author comes along

Nope. New Author trusted to long. He was there since ~2010

Module now has complexity in its build process an order of magnitude more complex than the functions it ships

When you look the LMU::PP only - yes. When you check the XS parts and the tickets referred in https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-88810202 - the complexity is much bigger than a quick look let one assume.

Module now as complexity that out strips most other modules at similar levels of utility by an order of magnitude ( Yes, XS considered )

The primary question is: "Do the other modules ignore some use-cases on the price of complexity?"

All those points should be discussed - and not ignored. #9 ignores that completely - let's blame the miscommunication for it. But to me

I am opening a different issue for the other problem as per https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-100223044.

speaks another language. The C::AC removal was the main intention of #9 - not the discussion of the complexity not the user-side test generation - the removal. Introductional statement in https://github.com/perl5-utils/List-MoreUtils/issues/11#issue-74640249 confirms.

@shadowcat-mst - list of some modules using C::AC https://github.com/ambs/Config-AutoConf/issues/5 was the reason I checked that - grep.cpan.me/?q=Config::AutoConf seems to have problems today. Maybe there's another CPAN grepper one can use and show ...

• https://metacpan.org/release/File-LibMagic
• https://metacpan.org/release/Unix-Statgrab

were the ones I'm using here and there and Unix::Statgrab was my playground (https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-99322617).

[kentfredric]

Here is the first wrong assumption. In Pure-Perl it might by simple complexity wise - the XS part is far away from being that simple.

Let me ask this differently: what kinds of problems does LMU have that make its internal complexity requirements higher than most other modules in the same level of utility?

I'm not talking about "What about operating systems" here, I want to know "what is in the guts that makes it complicated"

Essentially a collection of pure functions, no confusing architecture requirements

Yeah - such pure functions as each_array and natatime and RT#102673 (Summarize of collected wishlist entries).

Possibly a nuance lost in translation here, but I didn't mean to imply "all", only "Substantive number".

Functions do very rudimentary things with simple perl primitives

You can do stand-up comedy with that statement :)

Again, probably something lost in nuance. Its not a complex multi-layered system with objects with collections of objects, nor does it need network access to deal with any nasty REST apis, and correct me If I'm wrong, but it doesn't even really need to bind with any 3rd party libraries. It seems like "C89 and Perl is all you need". No?

Module has been shipped and used for 5 years without problem

Haha. Ticket list speaks a complete different language (bearing in mind the fundamental mistakes happened between hijacked co-maint and I recovered thanks to @dagolden).

This was not so much intended with as an "Needs features" or "API implied bugs". More, "It installs, and it installs without issue". Which seems to have been /mostly/ true. There are a bunch of compilation failures listed on RT, but I can't myself spot any which would have been solved by adding C:AC. If I am wrong, please feel free to list each and every RT Issue that relates to a problem C:AC solves which the competing code doesn't solve. I would not consider such a list "proof", but I would consider it "Good evidence". ( And if the details of individual RT's are sparse, I may have to ask for expansion ).

Module now as complexity that out strips most other modules at similar levels of utility by an order of magnitude ( Yes, XS considered )

The primary question is: "Do the other modules ignore some use-cases on the price of complexity?"

Right. I don't feel thats the only question, one has to distinguish between actual usecases and imagined ones. If one were to sit down and imagine all usecases possible, you'd have to ship LMU as bootable ISOs with different OSs on it. ( Yes, a hyperbolic case which is completely nonsense, intentionally constructed to suggest that not all usecases are "valid" )

This is the balancing equation you have to do, balancing out benefits vs costs.

If you go too hard into one aspect, your complexity grows to crazy levels to compensate. And if you go too hard in the other, then there's a total of one computer on the planet that runs your code. ( There are cases of that on CPAN >_> )

But I think we're actually in agreement that C:AC presently offers more complexity than you need, just there's no lower bar with less complexity that solves "your" needs.

[rehsack]

Here is the first wrong assumption. In Pure-Perl it might by simple complexity wise - the XS part is far away from being that simple.

Let me ask this differently: what kinds of problems does LMU have that make its internal complexity requirements higher than most other modules in the same level of utility?

I'm not talking about "What about operating systems" here, I want to know "what is in the guts that makes it complicated"

It runs on perl 5.6 - recent blead. The PadWalker API changed havily (multiple times, but that heavily every time). But what makes me initially adding C::AC was RT#93207. It took me several incarnations to figure out a solution which works with the pure perl API - beside tests.

I'm for both of the hot spot's at the moment unsure whether they're completely solved.

Essentially a collection of pure functions, no confusing architecture requirements

Yeah - such pure functions as each_array and natatime and RT#102673 (Summarize of collected wishlist entries).

Possibly a nuance lost in translation here, but I didn't mean to imply "all", only "Substantive number".

My reply was intended to open eyes for the internal difficulties. Especially the proposed behavior of iterators compared to lists makes me nervous ...

Functions do very rudimentary things with simple perl primitives

You can do stand-up comedy with that statement :)

Again, probably something lost in nuance. Its not a complex multi-layered system with objects with collections of objects, nor does it need network access to deal with any nasty REST apis, and correct me If I'm wrong, but it doesn't even really need to bind with any 3rd party libraries. It seems like "C89 and Perl is all you need". No?

The Perl API has changed heavily over time. Even when ppport.h helps a lot, it introduces it's own problems. An example which might need further research is the return stack size vs. list size (I32 vs. IV - ilmari pointed a few issues out which are completely ignored at the moment).

Module has been shipped and used for 5 years without problem

Haha. Ticket list speaks a complete different language (bearing in mind the fundamental mistakes happened between hijacked co-maint and I recovered thanks to @dagolden).

This was not so much intended with as an "Needs features" or "API implied bugs". More, "It installs, and it installs without issue". Which seems to have been /mostly/ true. There are a bunch of compilation failures listed on RT, but I can't myself spot any which would have been solved by adding C:AC. If I am wrong, please feel free to list each and every RT Issue that relates to a problem C:AC solves which the competing code doesn't solve. I would not consider such a list "proof", but I would consider it "Good evidence". ( And if the details of individual RT's are sparse, I may have to ask for expansion ).

https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-88810202 names them. The goal was to solve RT#75672 - but the loader test is missing (which is missing every where).

The reason for using C::AC was not to solve one particular ticket - it was to solve following:

• have a module which is reusable and fixes from one issue will automatically fix in every depending distribution
• have a sane (and complete) test whether XS and dynamically loading is supported (and permitted by user - mind PUREPERL_ONLY or -pm) by the perl we're running on (keeping cross-compiling and distributed package builds in mind)
• have the ability to solve all issues at customers with familiar approached (CC=..., CFLAGS=..., ac_cv_have_stdint_h=yes, ...)
• have a complete picture when something fails, what fails and why (config.log!)
• must be extensible for the case additional information are needed (sizeof(IV), IV_MAX vs. LONG_LONG_MAX, API availability where ppport.h provides empty placeholder, ...)

I looked around and there is no other module supporting that.

Module now as complexity that out strips most other modules at similar levels of utility by an order of magnitude ( Yes, XS considered )

The primary question is: "Do the other modules ignore some use-cases on the price of complexity?"

Right. I don't feel thats the only question, one has to distinguish between actual usecases and imagined ones. If one were to sit down and imagine all usecases possible, you'd have to ship LMU as bootable ISOs with different OSs on it. ( Yes, a hyperbolic case which is completely nonsense, intentionally constructed to suggest that not all usecases are "valid" )

Even when we reduce our selection of use-cases to "detect whether XS modules are reasonable in this environment" there is currently no solution on CPAN providing that coverage of "reasonable" as C::AC does.

This is the balancing equation you have to do, balancing out benefits vs costs.

If you go too hard into one aspect, your complexity grows to crazy levels to compensate. And if you go too hard in the other, then there's a total of one computer on the planet that runs your code. ( There are cases of that on CPAN >_> )

But I think we're actually in agreement that C:AC presently offers more complexity than you need, just there's no lower bar with less complexity that solves "your" needs.

Thanks :)

And I don't want to rush another solution - any new-comer must be proven for stability as I did with C::AC.

[kentfredric]

Just linking to the two RT articles directly for user convenience ( If @rehsack feels generous he could edit his comment to link to them and then this comment will be redundant ).

1. rt#93027 - LMU: minmax truncates intermediates to double
2. rt#75672 - Params::Utils: Loading Params::Util on Cygwin perl breaks ``

The latter of those two having a tl;dr of "Cygwin broke dynaloader in strange ways and broke perl itself and sniffing that out was hard, and bugs like that are a right dick to stumble over"

[rehsack]

As said - don't stick at the tickets only. They're part of the picture - even not the entire one.

grep.cpan.me is back in business - so I take the chance to copy the found dists from there (for those who still didn't look into https://github.com/ambs/Config-AutoConf/issues/5):

• Math::Int64
• Math::Int128
• File::LibMagic
• MaxMind::DB::Writer
• MaxMind::DB::Reader::XS
• Marpa::R2
• Lingua::PT::Speaker
• MongoDB
• re::engine::GNU
• AFS::PAG
• Lingua::NATools
• Lingua::Jspell
• SMOP
• Text::BibTeX
• Unix::Statgrab
• File::Listing::Ftpcopy
• FFI::Platypus
• Lingua::FreeLing3
• Lingua::Identify::CLD
• Search::Glimpse
• Tie::Cvs
• Tie::Ispell
• Net::Radio::Location::SUPL::XS

And maybe modules depending on those but don't name explicitely ...

[kentfredric]

The question for me is not "Where can CAC be used". But "Is it the right tool for this job". We both agreed already that it was too complex for this job, and the complexity only seems warranted because there was no lower solution.

Hence why I asked for a finite list of example problems that this module needs to solve, and a finite set of deliverables that this module needs to achieve.

Not a general mandate for problems for the whole of CPAN.

Your comment to that effect was adequate, and getting somebody who understands how to respond to it intelligently is now the quest.

[rehsack]

@kentfredric - @shadowcat-mst asked for that list.

Your comment to that effect was adequate, and

Thanks. I think maybe there is little light at the end of the tunnel ...

getting somebody who understands how to respond to it intelligently is now the quest.

As far as I know there is precisely one man for the job: @Leont - and he's busier than me :(

What is really important for future - the new tool must be in a way that allows C::AC build on that extended features without breaking list above.

[jddurand]

Seeing re::engine::GNU mentionned I just say that, if carefully coded, using C::AC works very well.

[rehsack]

There is maybe one thing I didn't express clearly enough:

LMU::XS will rely on C::AC.

But when (LMU+LMU::PP) and (LMU::XS) are split (or divorced?), I have very low arguments against switching in LMU to something compiler detecting only to add LMU::XS dependency. (I hope this is very clear).

[Leont]

This ticket has gone on a tangent, not unlike the previous one, I'm not even sure what the question is now, people are saying things but not really responding to the other. The fundamental problem is that the meta-discussion is being skipped: what makes a solution a good solution. Without that, this is not going anywhere.

[ribasushi]

This ticket has gone on a tangent

That much is true, however...

I'm not even sure what the question is now

@leont allow me to summarize. The original request (not a question) was stated in the opening of this ticket:

a formal request to @rehsack to remove C::AC from the configure_requires of List::MoreUtils until a widely accepted need for C::AC arises.

This was rejected here and here as:

... This is a formal reject of the request to remove Config::AutoConf ... there is no sane compiler test and the upcoming ExtUtils::HasCompiler is very untested and might be a solution when enough effort will be put into it.... There is maybe one thing I didn't express clearly enough: LMU::XS will rely on C::AC

I believe the above states the maintainers intentions and priorities rather clearly. Thus I believe trying to reopen the discussion of acceptable compiler detection on the backdrop of List::MoreUtils is counterproductive at best and more realistically a plain waste of time.

[rehsack]

This ticket has gone on a tangent

That much is true, however...

That probably intensional - the ticket is completely political motivated

I'm not even sure what the question is now

@leont allow me to summarize. The original request (not a question) was stated in the opening of this ticket:

a formal request to @rehsack to remove C::AC from the configure_requires of List::MoreUtils until a widely accepted need for C::AC arises.

Which can be phrased as "until a NOP statement switches the carry flag"

This was rejected here and here as:

... This is a formal reject of the request to remove Config::AutoConf ... there is no sane compiler test and the upcoming ExtUtils::HasCompiler is very untested and might be a solution when enough effort will be put into it.... There is maybe one thing I didn't express clearly enough: LMU::XS will rely on C::AC

I believe the above states the maintainers intentions and priorities rather clearly. Thus I believe trying to reopen the discussion of acceptable compiler detection on the backdrop of List::MoreUtils is counterproductive at best and more realistically a plain waste of time.

You never tried that. You tried to kick out something you don't trust and don't want to trust. The requests in issues#9 and here to clarify what is missing to make C::AC acceptable is still unanswered.

OTOH - meanwhile I agree. I do not intend to do new development for Perl 5 anymore.

[ribasushi]

You tried to kick out something you don't trust and don't want to trust.

This is correct. I do not see how this is in any way politically motivated. I am exercising my tendency (and in many ways obligation) to distrust questionable designs on technical merit alone.

The requests ... to clarify what is missing to make C::AC acceptable is still unanswered

Apologies on that front - it didn't occur to me there are still unclear parts there. To answer your question as clearly as possible: There is no acceptable scenario of using C::AC (or any other configure_requires-ed module) only for the purpose of detecting the presence of a compiler. Due to the proliferation of systems with non-existent configure_requires support, and the current push to generally avoid configure_requires altogether whenever possible, this state of things is unlikely to change at the very least until the year 2020, if not further in the future.

To reiterate - currently there is no scenario under which your current use of C::AC within LMU will magically become a good idea.

Also to state another obvious point - the above sentiment is my personal opinion. I am not speaking on behalf of the PTG nor any other group. The fact that nobody else contradicted me may be attributed to either failure to care or silent agreement or something entirely different. The sad truth is that we will never know.

[rehsack]

Well - to support those systems without configure_requires - the distribution comes with a bundle running down to Perl 5.6.configure_requires is not required. Since 5.6 was only added for you're support of 5.6 - I can remove that part to simplify Makefile.PL soonish...

The sad truth is that we will never know.

Qui tacet, consentire videtur. So we know. Nemo iudex in causa sua.

Age, quod agis! Ultima ratio: variatio delectat.

[dolmen]

If C::AC is used only to detect the presence of a compiler, that seems overkill for the task.

So, it seems to me that the political motivation is on the other side of the fence: to introduce C::AC in LMU, and then use that to push it further by claiming it has major users such as LMU.

[rehsack]

@dolmen - seems is not the same as is. I explained very detailed and very explicit what leads me to rely on C::AC. Please read it.

[kentfredric]

I think if I attempt to gingerly rephrase what Ribasushi is trying to say, is using C:AC "seems" to us like the situation one would have if somebody decided they want to use any of Moose/Moo/Class::Tiny in Makefile.PL, simply because they needed OO for something.

All of those would be deemed too complex for the task of simply needing ->new provided for you.

C:AC is seemingly similarly complicated at performing the small set of tasks you require.

But I think we already both agreed on that fact, there was just a problem of a lack of suitable tools that worked in the intermediate space that achieved the task.

[kentfredric]

I think this is a representation of where we are.

[rehsack]

Nope - this is maybe an impression of people who didn't dig into. When you do, you realize that the proportions are heavily wrong. But the real problem is - noone wants to get deeper into C::AC - but anybody judges about it and has opinion.

one would have if somebody decided they want to use any of Moose/Moo/Class::Tiny in Makefile.PL

Well - for a desired solution in a Makefile.PL extension, @shadowcat-mst suggests Role::Tiny and Class::MethodModifiers - I'm sure when I'm going to do it, it will get the same shitstorm as here :P

[kentfredric]

wholehearly agree - Config::AutoConf needs a lot of (attention, bike-shedding, renaming, splitting, ...) until a sane "reduced to the max" compiler test comes out. Do you remember since when I bug you to sit together to discuss the requirement of such checks, how long I wait for EU::CB successor (noted it to ambs/Config-AutoConf#6 as a reminder) to review and comment on, a brainstorming how we deal with the check/prove results to make such an "reduced to the max" check extensible and so on.

^ is what you said on the complexity. Did I misinterpret?

That very clearly says to me that "Yes, C:AC is far too complex, but the subset of behaviours I need I can't get any other way at present"

[rehsack]

^ is what you said on the complexity. Did I misinterpret?

That very clearly says to me that "Yes, C:AC is far too complex, but the subset of behaviours I need I can't get any other way at present"

Those attention is needed to get C::AC more "Perlish" - not functional. It might be reasonable to extract functality like check for external libraries - but for checking for reasonable XS capability, ~70%-80% of existing C::AC code is used and the load-check for host=target is still missing. The compiler detection code itself is not existing (uses ExtUtils::CBuilder with all pro's and con's) (https://rt.cpan.org/Ticket/Display.html?id=104690 gives an impression).

So not C::AC is far to complex, the problem itself is very complex and simplifying the problem to 90% use-cases is not the option I want to use.

[haarg]

Wait, after all of this discussion, Config::AutoConf doesn't even solve the problem it's being used for?

[rehsack]

Where did you read anything guiding you to such an assumption?

[Leont]

Here is the first wrong assumption. In Pure-Perl it might by simple complexity wise - the XS part is far away from being that simple.

I would disagree. The individual parts of LMU can be quite tricky to get right, but they're all fairly self-contained; The XS in LMU is difficult for sure, but it is not that complex. C::AC on the other hand is the opposite: it's a highly interdependent series of functions that usually don't do anything difficult individually. Needing "~70%-80% of existing C::AC code" to do something that common and well-scoped is the sort of thing that makes people uncomfortable with depending on it this far up the dependency river.

Even when we reduce our selection of use-cases to "detect whether XS modules are reasonable in this environment" there is currently no solution on CPAN providing that coverage of "reasonable" as C::AC does.

You haven't made a convincing case for that, to be honest. Your reasoning has a pattern of "look at these bugs, so Config::AutoConf is needed" without the intermediate steps, what is missing here is "what does it do different than other solutions" and "can the other solutions be fixed without having to introduce a large dependency".

The requests in issues#9 and here to clarify what is missing to make C::AC acceptable is still unanswered.

No one said the problem was that is was missing something, but it's costly in a number of ways (dependencies and risks). You can't change that by adding anything.

[Leont]

Where did you read anything guiding you to such an assumption?

Probably in the "The compiler detection code itself is not existing (uses ExtUtils::CBuilder with all pro's and con's)". I think you mean "configuring which compiler to use", and he interprets that as "detecting if we have a compiler".

[ribasushi]

@Leont Can you clarify how is this: ...configuring which compiler to use... practically different from this: ...detecting if we have a compiler...

[rehsack]

A way to ask for trouble is misusing permission. However ...

@Leont - all your questions were discussed in https://github.com/perl5-utils/List-MoreUtils/issues/11#issuecomment-100658664 .. https://github.com/perl5-utils/List-MoreUtils/issues/11#issuecomment-107840398.

You haven't made a convincing case for that, to be honest. Your reasoning has a pattern of "look at these bugs, so Config::AutoConf is needed" without the intermediate steps, what is missing here is "what does it do different than other solutions" and "can the other solutions be fixed without having to introduce a large dependency".

There is no single solution maintained where I could fill tickets for and could fetch updates from (beside all details from https://github.com/perl5-utils/List-MoreUtils/issues/11#issuecomment-100782050). Show one existing solution satisfying the mentioned requirements or someone who is willing to maintain and we going to have a deal. As long as there is no such thing - the best solution is the existing one, how bad it ever might be ...

No one said the problem was that is was missing something, but it's costly in a number of ways (dependencies and risks).

Wrong: I said that.

[ribasushi]

A way to ask for trouble is misusing permission. However ...

@rehsack I didn't abuse anything. Github-wide the person who opened the ticket originally has permission to close it regardless of the rest of their permission levels (here is an example, I do not have any access to that repository).

Since my issue stalemated 3 weeks ago, after wasting a ton of time for many people, I decided to close it. I have no problem with keeping it open however.

Cheers!

[rehsack]

Regardless the source of the permission (admin, creator), such a large discussion shouldn't be simply closed - you can suggest a close, as you don't see any progress.

OTOH - you have your conclusion either, disable notifications and maybe others benefit from it or not.

[shadowcat-mst]

With all due respect Sno ... piss off.

There was no abuse involved. You just happened to disagree as to where the 'closed' flag should be set or not. Don't make a big deal of it.

github lets you keep commenting on the thing anyway so it barely makes any difference - locking the issue might've mattered but only you can do that, not riba, so that's completely irrelevant.

In any case, this issue is closed - List::MoreUtils is now filed under "maintainer would be safer if they stuck to node.js and left the real programming to the adults" and we're working on eliminating it from the dependency chain of anything important.

We're done here. Click whatever buttons on github makes you happy but don't waste my time with stupid shit.

[Leont]

@Leont - all your questions were discussed in #11 (comment) .. #11 (comment).

The issue in the first comment is something I fixed by modifying two lines of code, that's not exactly a convincing argument for the necessity of C::A.

As for the second comment, I'm not sure what answer in it is. Pulling in a large configure time dependency is not a logical solution when adding a simple cast to the C source would have solved it much more reliably.

There is no single solution maintained where I could fill tickets for and could fetch updates from (beside all details from #11 (comment)). Show one existing solution satisfying the mentioned requirements or someone who is willing to maintain and we going to have a deal. As long as there is no such thing - the best solution is the existing one, how bad it ever might be ...

AFAICT EU::HC satisfies all those requirements except extensibility, but like I said before I don't see how we need any kind of extensibility in this case.

[rehsack]

As for the second comment, I'm not sure what answer in it is. Pulling in a large configure time dependency is not a logical solution when adding a simple cast to the C source would have solved it much more reliably.

It's not only more reliable - it's more helpful when debugging or admins/packagers/... want to override something without going down the deep of hacking a EU::HC extension overriding the Config handling.

AFAICT EU::HC satisfies all those requirements

Let's check:

have a module which is reusable and fixes from one issue will automatically fix in every depending distribution

True

have a sane (and complete) test whether XS and dynamically loading is supported (and permitted by user - mind PUREPERL_ONLY or -pm) by the perl we're running on (keeping cross-compiling and distributed package builds in mind)

Not (yet) true, but I can see the opportunities given by EU::HC

have the ability to solve all issues at customers with familiar approached (CC=..., CFLAGS=..., ac_cv_have_stdint_h=yes, ...)

Not true

have a complete picture when something fails, what fails and why (config.log!)

Not true

must be extensible for the case additional information are needed (sizeof(IV), IV_MAX vs. LONG_LONG_MAX, API availability where ppport.h provides empty placeholder, ...)

Not true

except extensibility, but like I said before I don't see how we need any kind of extensibility in this case.

I see it - and I think I gave enough examples why. Because of this I don't want to have module A for limited use case and a complete different module B for extensible use case. Just design module A being extensible without providing to much stuff.

And: EU::HC is bleeding edge compared to C::AC. I was totally fine to switch to EU::HC one fine day later when it's more mature and supports the relevant features. Meanwhile I think this is difficult for several reasons - more personal and political ones than technical reasons.

[ribasushi]

Because of this I don't want to have module A for limited use case and a complete different module B for extensible use case.

This is the main point of disagreement. I (and seemingly others) want precisely this - one module to do compiler detection and nothing else, with an architecturally engineered impossibility to add any extra functionality down the road. If it becomes extensible, and gains bells and whistles and so on and so forth - it will essentially have all the same problems as C::AC.

[rehsack]

Oh my - I've already explained why I think some additional checks might be necessary, but that's completely discussed and as far as the requirement doesn't come up I don't intend introduce overcomplex extensible stuff ahead. The time C::AC was introduced, nothing else was available.

The archirecture to make EU::HC extensible can be easy - have a sane, structured cache as other configuration detector show. Extend by derive or add roles. Totally fine - and maybe for tiny extensions a 10-liner in inc/.

[Leont]

AFAICT EU::HC satisfies all those requirements

Let's check:

I moved this to a separate ticket

[rehsack]

It's not only more reliable - it's more helpful when debugging or admins/packagers/... want to override something without going down the deep of hacking a EU::HC extension overriding the Config handling.

I'm not sure what you're trying to say here.

I know (and this is not an accusation).

Please try following:

1) Download more or less recent LMU (or maybe Unix::Statgrab, File::LibMagic, ...) and run Makefile.PL. 2) Download more or less recent rrdtool (graphviz, ...) and run ./configure

for both (or all) - check the config.log (LMU seems quite managable - Unix::Statgrab shows better even in successful cases). Such config.log's contain lines like

Checking for sg_fs_stats.device_canonical ...compile stage failed - error building testt5fIvM.o from 'testt5fIvM.c' at /Users/sno/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/ExtUtils/CBuilder/Base.pm line 173.

testt5fIvM.c:43:18: error: no member named 'device_canonical' in 'sg_fs_stats'
  if( check_aggr.device_canonical )
      ~~~~~~~~~~ ^
1 error generated.

failing program is:
/* end of conftest.h */

I cited some examples above and in issue#9 why the logging behaviour and setting architecture of C::AC helps to provide quick solutions at user side when something fails. I think it would be necessary to explain the details in a workshop or hackathon or whatever ...

[ribasushi]

A failure I experienced today: the compiler detection does not work at all when cc exists but is not a compiler. Reproducible via the following steps:

rabbit@Ahasver:~$ ln -s /bin/true ~/bin/cc

rabbit@Ahasver:~$ ls -l $(which cc)
lrwxrwxrwx 1 rabbit rabbit 9 Feb 18 15:32 /home/rabbit/bin/cc -> /bin/true

rabbit@Ahasver:~$ cpanm --look List::MoreUtils
--> Working on List::MoreUtils
Fetching http://www.cpan.org/authors/id/R/RE/REHSACK/List-MoreUtils-0.413.tar.gz ... OK
Entering /home/rabbit/.cpanm/work/1455805966.22298/List-MoreUtils-0.413 with /bin/bash

rabbit@Ahasver:~/.cpanm/work/1455805966.22298/List-MoreUtils-0.413$ perl Makefile.PL 
Checking whether pureperl is required... no
Checking for cc... cc
Checking for cc... (cached) cc
Checking whether perlapi is accessible... yes
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for List::MoreUtils
Writing MYMETA.yml and MYMETA.json

rabbit@Ahasver:~/.cpanm/work/1455805966.22298/List-MoreUtils-0.413$ grep '\.xs' Makefile
#     XS => { MoreUtils.xs=>q[MoreUtils.c] }
DLSRC = dl_dlopen.xs
XS_FILES = MoreUtils.xs
.SUFFIXES : .xs .c .C .cpp .i .s .cxx .cc $(OBJ_EXT)
.xs.c:
    $(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(XSUBPP_EXTRA_ARGS) $*.xs > $*.xsc && $(MV) $*.xsc $*.c
.xs$(OBJ_EXT):
    $(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc && $(MV) $*.xsc $*.c

rabbit@Ahasver:~/.cpanm/work/1455805966.22298/List-MoreUtils-0.413$ make
cp lib/List/MoreUtils.pm blib/lib/List/MoreUtils.pm
cp lib/List/MoreUtils/XS.pm blib/lib/List/MoreUtils/XS.pm
cp lib/List/MoreUtils/Contributing.pod blib/lib/List/MoreUtils/Contributing.pod
cp lib/List/MoreUtils/PP.pm blib/lib/List/MoreUtils/PP.pm
Running Mkbootstrap for List::MoreUtils ()
chmod 644 MoreUtils.bs
/home/rabbit/perl5/perlbrew/perls/5.16.2/bin/perl /home/rabbit/perl5/perlbrew/perls/5.16.2/lib/site_perl/5.16.2/ExtUtils/xsubpp  -typemap /home/rabbit/perl5/perlbrew/perls/5.16.2/lib/5.16.2/ExtUtils/typemap  MoreUtils.xs > MoreUtils.xsc && mv MoreUtils.xsc MoreUtils.c
cc -c  -I. -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2   -DVERSION=\"0.413\" -DXS_VERSION=\"0.413\" -fPIC "-I/home/rabbit/perl5/perlbrew/perls/5.16.2/lib/5.16.2/x86_64-linux-thread-multi-ld/CORE"   MoreUtils.c
rm -f blib/arch/auto/List/MoreUtils/MoreUtils.so
cc  -shared -O2 -L/usr/local/lib -fstack-protector MoreUtils.o  -o blib/arch/auto/List/MoreUtils/MoreUtils.so   \
        \

chmod 755 blib/arch/auto/List/MoreUtils/MoreUtils.so
chmod: cannot access ‘blib/arch/auto/List/MoreUtils/MoreUtils.so’: No such file or directory
Makefile:489: recipe for target 'blib/arch/auto/List/MoreUtils/MoreUtils.so' failed
make: *** [blib/arch/auto/List/MoreUtils/MoreUtils.so] Error 1

It has been over a year - can this be finally fixed, please.

[rehsack]

This false positiv is intensional. You don't want to use LMU, please stop caring.

When people are interested in real fixes, I'm there and open for discussions.