Re^4: How to properly use ExtUtils::MakeMaker PL

See Linux::NFS::BigDir. Is that the module you're working on?

Yes, I'm the author of Linux::NFS::BigDir.

How often in the past 20 years has that number you're fetching from the header changed? It should be easy to lookup

If I could rely on h2ph, yes, but I can't. Linux distributions have a variation of locations there they think it the best way to keep C header files. On the other hand, they don't distribute broken C libraries, so it is safe to assume I can use it to get the constant.

Instead of generating a throwaway module so you can inline a constant, you should be generate a data file, using the "official" way for data files File::ShareDir / File::ShareDir::Install

That will probably give me a maintenance headache: we just need a new processor coming up or anything else that justify changing that constant.

Alceu Rodrigues de Freitas Junior
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

Comment on Re^4: How to properly use ExtUtils::MakeMaker PL_FILES attribute? Download Code

Replies are listed 'Best First'.
Re^5: How to properly use ExtUtils::MakeMaker PL_FILES attribute? by Anonymous Monk on Jun 04, 2017 at 08:29 UTC
If I could rely on h2ph, yes, but I can't. Linux distributions have a variation of locations there they think it the best way to keep C header files. On the other hand, they don't distribute broken C libraries, so it is safe to assume I can use it to get the constant. Um, no, thats not what I'm talking about. Header files are created by humans, they're source code. In big projects, like gui libraries, mfc, wxwidgets, header numbers do not change ever, for 5/10/15/20 years and more. New headers get added. Old numbers do not change. I'm not suggesting you use h2ph , I'm suggesting you use your eyes, track down every copy of the header file that ever existed, like in some kind of git repository, and compare the number today to the number it was 50 years ago Do it for all "official" source code repository that manages this header file Its like, you're not compiling/interfacing any c/xs code -- headers are just #define ... that stuff doesn't change :) That will probably give me a maintenance headache: we just need a new processor coming up or anything else that justify changing that constant. Hehe, um, no, that is not a maintenance headache, you just keep doing exactly what you're doing right this moment, except instead of Inline ... in Makefile.PL, only so you can insert `sub CONSTANT(){12}` into Foo.pm, all you do is have Foo.pm read from foo-dist/constant.txt when its loaded Its like h2ph, you require "constants.ph" or whatever, you don't inline the source of constants.ph into your module.pm Its like how much time you want to spend figuring out your makemaker for a single solitary constant	[reply] [d/l]
Re^6: How to properly use ExtUtils::MakeMaker PL_FILES attribute? by glasswalk3r (Friar) on Jun 06, 2017 at 13:47 UTC
I'm quite aware of how C header files are supposed to work, but I understand your point here, considering that I'm struggling to achieve dynamic fetching and generation of the respective module/constant. I guess the usage `h2ph` or even the ExtUtils::Makemaker solutions should work for that, considering how mature they should be. But that's not reality, as it seems. For now, I'm aware of 3 different values for that specific system call constant (32 and 64 bits processor and ARM). I could use the Makefile.PL to check the environment and compare with a hash or something else, but soon or later I'll have to update it... and I'm too lazy for that. :-) Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply] [d/l]