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 #9 as a lie ("it's only about user-side test generation")

Err... #9 was (at least to me) chiefly about user-side test generation. That issue was mostly addressed by 91f51eae, which I acknowledged right here: #9 (comment).

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

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 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.

C::AC uses similar compile checks as you're EU::HC does - with the difference of the ability fixing ambs/Config-AutoConf#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 #9 (comment) - 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 #9 (comment).

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 #11 (comment) confirms.

@shadowcat-mst - list of some modules using C::AC
ambs/Config-AutoConf#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 (#9 (comment)).

[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.