(this is the second part of bug 240227 ) Currently emake dies when Makefile is not found, I suggest change this behavior to simply skipping "make" stage. You will see (like with configure) that some eclass and a lot of ebuilds are already workarounding current portage behavior running things like "true" or "einfo..." Attached patch will make "emake" to simply skip make stage when Makefile is not present, this is a common case with some binary packages or apps that need a trivial installation. My proposed emake will check the following before skipping: 1. Will check for "Makefile", "makefile" and "GNUmakefile", as shown in "make" man page, seems that these are the common names for makefiles. In case any of these files are found, emake will run as currently 2. If an ebuild is using "-f" option for specifying other makefile, emake will still use it as is doing currently. For this I use "getopts", maybe it is not perfectly used because I never used it before and I have learned to use it reading bash man page and seeing and script for converting dvds to vcds Then, in summary, the behavior with the patch will be the following: If any makefile is found, it will run as currently, if not, a warning will be shown for letting maintainer know the situation: * emake: Makefile not found, skipping make stages..." Thanks a lot for considering this :-) Reproducible: Always
Created attachment 167435 [details, diff] emake.patch
This sort of change requires an EAPI bump since we don't want ebuild authors relying on new behavior in ebuilds that might be installed by an older version of portage.
why exactly do you want this change ? this smells like a bad idea all over. i dont want `emake` trying to magically guess my intentions and just screwing it all up. obvious errors in your code and your proposal: you dont handle the -C or -f options. you dont handle implicit rules (there are some ebuilds in the tree that use `emake` and no makefiles via implicit rules). you also provide no actual examples of how this proposal would help. all in all, i propose we close this as WONTFIX.
(In reply to comment #3) > why exactly do you want this change ? this smells like a bad idea all over. i > dont want `emake` trying to magically guess my intentions and just screwing it > all up. > > obvious errors in your code and your proposal: you dont handle the -C or -f > options. you dont handle implicit rules (there are some ebuilds in the tree > that use `emake` and no makefiles via implicit rules). > > you also provide no actual examples of how this proposal would help. all in > all, i propose we close this as WONTFIX. > I agree that patch has that pointed issues :-S, but, about why I want that behavior, I think that I have explained it already on my first post: "You will see (like with configure) that some eclass and a lot of ebuilds are already workarounding current portage behavior running things like "true" or "einfo..." " "Attached patch will make "emake" to simply skip make stage when Makefile is not present, this is a common case with some binary packages or apps that need a trivial installation."
i asked for real examples. copying & pasting your summary provides none. considering the downsides i listed that are impossible to work around if your version is implemented, the theoretical gains dont come close to outweighing them. you also have no way of catching issues where a makefile is supposed to be generated but due to some random error, it is not. your emake would then be silently skipped. if you wanted to propose a new command like "maybe_emake" that did all this kind of magical guesswork, i wouldnt care. but breaking "emake" isnt acceptable.
(In reply to comment #5) > i asked for real examples. copying & pasting your summary provides none. > > considering the downsides i listed that are impossible to work around if your > version is implemented, the theoretical gains dont come close to outweighing > them. you also have no way of catching issues where a makefile is supposed to > be generated but due to some random error, it is not. your emake would then be > silently skipped. > It wouldn't be "silently" skipped, a " * emake: Makefile not found, skipping make stages..." message would be shown > if you wanted to propose a new command like "maybe_emake" that did all this > kind of magical guesswork, i wouldnt care. but breaking "emake" isnt > acceptable. > But, yes, maybe a "maybe_emake" or some standarized way for trying to unify current workarounds like running "true", "einfo"... would work and also don't touch emake :-/, then, it would be much better
ok, it wouldnt be "silently" skipping the step, but it would practically be the same thing. if you're ok with a new command, then simply add it to eutils and merge the eclasses/ebuilds you refer to indirectly. you could do that today and post it to the mailing list, and you could use it in all EAPIs instead of just the latest ones.
I will do it as soon as I am able to (I am now too busy but I expect to have enough time at mid-february or so) Thanks for reviewing this and sorry for the inconvenience
After rethinking it, seems that adding a new command to simply run "einfo "Nothing to compile" doesn't make much sense :-/
