Unacceptable use of Config::AutoConf for compiler-detection. #11
Comments
|
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). |
Nod. This is sufficient written record for others to justify "we need to switch away" arguments elsewhere.
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.
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. |
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.
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. 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.
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. |
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)
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. |
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.
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. |
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.
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.
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. |
raises hand |
|
Try to see it from our perspective:
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". |
^ 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". |
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. |
|
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. |
|
@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): 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! |
|
@kentfredric - allow me to respond:
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.
Yeah - such pure functions as each_array and natatime and RT#102673 (Summarize of collected wishlist entries).
You can do stand-up comedy with that statement :)
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).
Nope. New Author trusted to long. He was there since ~2010
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.
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
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 were the ones I'm using here and there and Unix::Statgrab was my playground (#9 (comment)). |
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"
Possibly a nuance lost in translation here, but I didn't mean to imply "all", only "Substantive number".
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?
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 ).
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. 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. |
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.
My reply was intended to open eyes for the internal difficulties. Especially the proposed behavior of iterators compared to lists makes me nervous ...
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).
#9 (comment) 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:
I looked around and there is no other module supporting that.
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.
Thanks :) And I don't want to rush another solution - any new-comer must be proven for stability as I did with C::AC. |
|
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 ).
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" |
|
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 ambs/Config-AutoConf#5):
And maybe modules depending on those but don't name explicitely ... |
|
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. |
|
@kentfredric - @shadowcat-mst asked for that list.
Thanks. I think maybe there is little light at the end of the tunnel ...
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. |
|
Seeing re::engine::GNU mentionned I just say that, if carefully coded, using C::AC works very well. |
|
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). |
|
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. |
That much is true, however...
@Leont allow me to summarize. The original request (not a question) was stated in the opening of this ticket:
This was rejected here and here as:
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. |
That probably intensional - the ticket is completely political motivated
Which can be phrased as "until a NOP statement switches the carry flag"
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. |
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.
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 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. |
|
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...
Qui tacet, consentire videtur. So we know. Age, quod agis! Ultima ratio: variatio delectat. |
|
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. |
|
@dolmen - |
|
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 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. |
|
Nope - this is maybe an impression of people who didn't dig into. When you do, you realize that the proportions are heavily wrong.
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 |
^ 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. |
|
Wait, after all of this discussion, Config::AutoConf doesn't even solve the problem it's being used for? |
|
Where did you read anything guiding you to such an assumption? |
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.
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".
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. |
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". |
|
@Leont Can you clarify how is this: |
|
A way to ask for trouble is misusing permission. However ... @Leont - all your questions were discussed in #11 (comment) .. #11 (comment).
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 ...
Wrong: I said that. |
@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! |
|
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. |
|
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. |
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.
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. |
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.
Let's check:
True
Not (yet) true, but I can see the opportunities given by EU::HC
Not true
Not true
Not true
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. |
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. |
|
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/. |
I moved this to a separate ticket |
I know (and this is not an accusation). Please try following:
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 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 ... |
|
A failure I experienced today: the compiler detection does not work at all when It has been over a year - can this be finally fixed, please. |
|
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. |
|
Reworked as intended - even if the root cause is and will remain unsolved, this request is done. |
As pointed out by mst in issue#24 it must be clear which code is released under which license and re-licensing old code requires permission of all authors. To make it clear to anyone: any code release after 0.416 (or much more precise: code from me with begin of commit d32dfb4), code from contributors after this commit. Confused? Send your thanks to people bugging code should be moved to List::Util, List::SomeUtils etc. Signed-off-by: Jens Rehsack <sno@netbsd.org>
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_requiresof List::MoreUtils until a widely accepted need for C::AC arises.The text was updated successfully, but these errors were encountered: