Pe 15 oct. 2017 12:57 PM, "SF Markus Elfring" <elfr...@users.sourceforge.net> a scris:
> Are the chances better to extend the tool “remake” then? … > Probably. Can it be that our software development resources are also too limited for mentioned tasks? I don't know. > My intention was to provide profiling information by default … This is generally fine. Do any collaboration challenges hinder to achieve further improvements in this direction? I would say the problem is that opportunity is long gone. No time and motivation on my side. > The dependency graphing feature was also present in the branches > I was planning to upstream since it allowed me to check > if the dependencies in our build system were incorrect from a logical PoV > (started with a sequential build) This information sounds promising. Did you clarify any remaining open issues with involved maintainers (in the background)? All information is public. From the get go it was clear to me that the usability and practical side of the proposal and how the feature should be used was considered secondary (or not say all) to the desire to have a complex and impractical solution based on xml. Quote: "I'm not so excited about adding the formatting capability, at least not this way. I think that it could be a very useful thing to allow for specially-formatted output from GNU make. For example, perhaps an output format in XML that could be easily sucked into tools like Eclipse or whatever for further parsing (I'm not a huge fan of XML but it is relatively universal). Now that we have the output sync capability it would be straightforward to combine these and format the output of recipes for proper XML encoding as well." That sole idea made it clear to me the use case was not understood and I tried to explain why the xml output was only a good option only on paper, but lacked in the usability aspect (your regular developer working on optimizing a gnu make based build framework will not care about using xml parsers, but prefer a very tight change-build-test cycle, so using awk or shell ours the best option here) . I received 0 feedback after the reply quoted above, even after reworking the patches to go in the directions suggested without sacrificing the feature entirely. TBH, I was very disappointed by this attitude and know that it is possible to run projects in a minute constructive manner, and also know there are better make flavours or there which allow better debugging and make the developer life easier instead of painful. Eddy
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
