Howard, Thank you for your feedback. I think an example would best justify the improvements that trimpath and relpath would bring to GNU Make. In fact, I will give the actual example that motivated me to develop trimpath the relpath in the first place. We can generalize from that starting point. First a little background...
My build system is developed using GNU Make and it separates the build system repository, from the project's source tree/repository that makes use of it. This allows multiple teams, developing different projects, in different repositories to incorporate the features of this build system, separate from the team's project repository. As a result, I need some pathing variables to traverse back and forth between the repositories, which result in long relative paths. I have basically applied the FTSE to the build system. Here is an sample compiler invocation: g++ -g -O0 -fshort-wchar -DGTEST_USE_OWN_TR1_TUPLE=1 -I. -I../../../_make_interface/../../../_make_system/source/_make_interface/../common/headers - I../../../_make_interface/../../../xseries/source/_make_interface/../common/headers - I../../../_make_interface/../../../xseries/source/_make_interface/../common/libs/algorithms - I../../../_make_interface/../../../xseries/source/_make_interface/../common/libs/asserting - I../../../_make_interface/../../../xseries/source/_make_interface/../common/libs/mathfuncs - I../../../_make_interface/../../../xseries/source/_make_interface/../common/libs/protocols - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/controllers - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/discrete - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/filters - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/flowcassette - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/linear - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/lookuptables - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/nonlinear - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlblocks/patterngenerators - I../../../_make_interface/../../../xseries/source/_make_interface/../vent/libs/controlframework -c nonlinear/AbsDifferenceBlock.cpp -o _debug/tdd/obj_controlblocks/AbsDifferenceBlock.cpp.o It became obvious to me that these paths were unnecessarily long, and I desired an API to shorten them (I could not shorten the generation of these paths without giving up certain features of the build system). Applying $(relpath ... ) to these search paths results in the following compiler invocation: g++ -g -O0 -fshort-wchar -DGTEST_USE_OWN_TR1_TUPLE=1 -I. -I../../../../../_make_system/source/common/headers -I../../../common/headers -I../../../common/libs/algorithms - ../../../common/libs/asserting -I../../../common/libs/mathfuncs -I../../../common/libs/protocols -I../../../vent/libs/controlblocks -I../../../vent/libs/controlblocks/controllers -I../../../vent/libs/controlblocks/discrete -I../../../vent/libs/controlblocks/filters -I../../../vent/libs/controlblocks/flowcassette - I../../../vent/libs/controlblocks/linear -I../../../vent/libs/controlblocks/lookuptables -I../../../vent/libs/controlblocks/nonlinear -I../../../vent/libs/controlblocks/patterngenerators -I../../../vent/libs/controlframework -c nonlinear/AbsDifferenceBlock.cpp -o _debug/tdd/obj_controlblocks/AbsDifferenceBlock.cpp.o This was much easier to read, likely faster to execute, and better overall. Now to answer your two points: 1) Yes, if my directory structure is built with "weirdly symlinked build trees", than I should not use a function to remove seemingly unnecessary pathing elements. In general, I would advise against "weirdly symlinked build trees". :) This function still has great usability otherwise. 2) Certain compilers have an input buffer size limitation, and this function can put the compiler invocation under that limit. I agree that is not a good solution in general, and if I continued to add more paths, I would eventually end up over that limit. From a practical perspective however, relpath put me far below that limit, when I was far above that limit, and was practically very useful. Regards, Ben Robinson, Ph.D. On Mon, May 30, 2011 at 12:27 PM, Howard Chu <h...@highlandsun.com> wrote: > Ben Robinson wrote: > >> Eli, >> >> Thank you for your constructive criticism regarding my submission to GNU >> Make. >> I perceive the critiques to fall into three categories (documentation, >> justification and code improvements) which I will respond to in order. >> >> *Documentation*: You are correct, these functions remove only "redundant" >> or >> "unnecessary" . and .. components. The suggested documentation should >> instead >> read: >> >> $(trimpath names|...|) >> For each file name innames,returns a name that does not contain >> >> any|unnecessary.|or|..|components, nor any repeated path separators (|/|). >> Canonical absolute names remain canonical absolute, and relative names >> remain relative. >> >> $(relpath names|...|) >> For each file name innames,returns the relative path to the file. This >> relative path does not contain anyunnecessary |.|or|..|components, nor any >> >> repeated path separators (|/|). >> >> *Justification (trimpath)*: trimpath can be used to shorten the input >> strings >> to compilers/linkers, as well as improve readability to the user. Certain >> compilers have a maximum number of characters which can be passed into a >> single invocation of their compiler. In my project, I had a dozen or so >> -include<search_path> which contained many unnecessary . and .. >> components, >> which caused the compiler to overflow the input buffer. While it is >> unfortunate compilers exist with unreasonably small input buffers, >> trimpath >> allowed me to only pass in the minimum number of characters required >> to successfully compile. >> > > Pretty weak. If a few more include paths were added to the project it would > still break, regardless of your patch. > > > Also, the readability of paths printed to the console is greatly improved >> by >> trimpath. I was regularly dealing with paths of the following structure: >> >> >> -I../../../_make_interface/../../../_make_system/source/_make_implementation/../3rdparty/libs/gtest/include >> >> >> which would be reduced by trimpath to: >> >> -I../../../../../_make_system/source/3rdparty/libs/gtest/include >> > > At first glance this sounds like a good thing, but it seems to miss the > possibility of weirdly symlinked build trees, where "foo/bar/.." != "foo". > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
