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

Reply via email to