Re: New Feature Submission for GNU Make
I like what I see ;-) I haven't looked at the code, but one warning: it's important to not assume that blah/../foo/ is equivalent to foo/ - blah might be a symlink. *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. Even the shell has an upper bound on how long a command-line it's willing to be given; it's pretty big, but I've hit that when invoking ar. Being able to shorten the path in this way would indeed delay the point at which a project hits such limits. Using trimpath may also be helpful in some cases as a way to canonicalise filenames (without changing whether they're absolute or relative), which is important when dealing with dependencies - ISTR that, if the rule to make a file spells its name one way and the declaration that something else depends on that file spells it differently, make won't notice that the two references are actually to the same file; you'll get a no rule to make error instead of making the needed file. One can of course use abspath for canonicalisation; but it is apt to make command-lines longer; and it causes the output of make to depend wantonly on the checkout directory, where systematic use of relative paths leaves it easy to diff the output of different builds to detect new warnings from the compiler and other changes that should be checked up on. This is, of course, also an argument for relpath ... *Justification (relpath)*: Similiar to trimpath, relpath can be used to shorten the input strings to compilers/linkers, as well as improve readability to the user. When relative paths are used with care, it's even possible to rename a source tree and its output directory (including assorted .d files recording dependencies) and remake without problems, as long as the relative paths between the two are unchanged, where abspath would force one to invalidate all the prior build's dependency information (and thus, in effect, do a full re-build just to recreate it, no matter how little actually needed re-built). Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: New Feature Submission for GNU Make
Pretty weak. If a few more include paths were added to the project it would still break, regardless of your patch. When you have thousands of object files, shortening the name of each by several bytes when invoking ar can make room for really quite a lot more files before you run up against the command-line length limit. Never understimate the value of a modest shortening of file names - when our ar command-line got to about 230 kibibytes, we had to re-work the way we invoked ar ! Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: New Feature Submission for GNU Make
On Tue, 31 May 2011 20:57:10 +0900, Edward Welbourne e...@opera.com wrote: I haven't looked at the code, but one warning: it's important to not assume that blah/../foo/ is equivalent to foo/ - blah might be a symlink. While this is true, I am not sure one which side this should be solved. Simply not treating blah/../foo/ as equivalent to foo/ would greatly reduce what the proposed patch can do. Assuming good documentation, would it be unreasonable to expect the user of GNU make to know what he is doing, and to avoid using the functions as they are proposed if their build tree contains directory symlinks? If we want to solve this in the proposed functions, assuming blah is a symlink to some/other/path, $(trimpath blah/../foo/) should return some/other/foo/. But if we want to let the user decide, we can keep trimpath as it is, and introduce resolve-symlinks, so that $(trimpath $(resolve-symlinks blah/../foo/)) can be used to get some/other/foo/, while $(trimpath blah/../foo/) can be used to get foo/ If you do have a tree that contains symlinks to directories, I can't really imagine a situation where you wouldn't want the symlink resolution. But then again I am sure my imagination has limits. As for trees that don't have symlinks to directories, the only benefit of the current implementation (without symlink resolution) would be performance, as you don't have to query the file system. I am inclined to think that given that overhead of symlink resolution would be fairly low in absolute terms, and that there appears to be no valid uses of trimpath without symlink resolution on trees that do contain symlinks, trimpath would benefit from being rewritten to resolve symlinks, but I wouldn't be surprised to be proven wrong on either of my assumptions. - Florian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: New Feature Submission for GNU Make
On Tue, May 31, 2011 at 8:06 AM, Edward Welbourne e...@opera.com wrote: Never understimate the value of a modest shortening of file names - when our ar command-line got to about 230 kibibytes, we had to re-work the way we invoked ar ! My vote would be favorable as well. There are a number of subtleties which should not be underestimated: - Really long lines in a logfile makes it hard to visually process them and detect errors or warnings. - Long lines cause logfiles themselves to take up more space which can cause them to fill partitions, force an organization to carry fewer old logs, etc. Where I work we have a nightly build report with clickable links to logfiles. It can take quite a while for a browser to load up a big logfile, especially for colleagues working over slow lines. - As noted before, the ability to compare logfiles with relativized paths is helpful, as is the ability to take the failing command line from someone else's build output and copy and paste it into your workspace for debugging. - Objects built for debug tend to have full paths to source files built in. Shortening the paths can thus shrink the objects themselves and make debugging more easily portable. Also some organizations may want to ship debug objects without exposing their internal development infrastructure. Of course it's possible to do some relativizing now with a combination of abspath and subst, but it's not fully robust. I think that canonpath would be a better name than trimpath; more mnemonic, more standard. David Boyce ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: New Feature Submission for GNU Make
Edward Welbourne wrote: Pretty weak. If a few more include paths were added to the project it would still break, regardless of your patch. When you have thousands of object files, shortening the name of each by several bytes when invoking ar can make room for really quite a lot more files before you run up against the command-line length limit. Never understimate the value of a modest shortening of file names - when our ar command-line got to about 230 kibibytes, we had to re-work the way we invoked ar ! Whatever you're doing, you're doing it wrong. ;) If you're tossing a bunch of object files into an ar library simply for grouping purposes, and all of the object files will eventually be used in the final executable, it's faster to use ld -r and combine groups of them all into a single object file. If you profiled your build I'm sure you would find that a large percentage of time is being wasted in ar itself. And if you're really running a build with thousands of object files, on a frequent basis, you're foolish not to profile it and figure out what else you're doing wrong. Giant monolithic command lines also prevent you from leveraging parallel make, so that's another reason not to do things that way... -- -- 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
