I'm attaching a proposed patch. I wrote the recipe as "@test -e ./$@ || ln -sv ../$@" rather than just the ln command to make 100% sure it doesn't try to recreate an existing link. AFAICT it works for me. I don't know why it rebuilds auto/pathdef.c, objects/pathdef.o and objects/version.o even though they aren't supposed to have changed.
Best regards, Tony. On Fri, Aug 30, 2019 at 2:00 PM Bram Moolenaar <[email protected]> wrote: > > > Tony wrote: > > > On Thu, Aug 29, 2019 at 8:59 PM Bram Moolenaar <[email protected]> wrote: > > > > > > > > > Christian wrote: > > > > > > > On Mi, 28 Aug 2019, Bram Moolenaar wrote: > > > > > > > > > > > > > > > Recently you've been proposing (and Bram has accepted) to create a > > > > > > lot > > > > > > of new source files to make the existing source easier to > > > > > > understand. > > > > > > The notion is laudable but it doesn't work well with my shadow > > > > > > directories: every time there is a new .c source (or .h; .pro > > > > > > sources > > > > > > are taken care of automatically by virtue of their being in a > > > > > > special > > > > > > src/proto directory for which a symlink has ben creted once and for > > > > > > all in the shadow directory), I have to manually create a symlink > > > > > > newsourcename.c -> ../newsourcename.c in each shadow directory, > > > > > > otherwise the "make" step ends in error with "No rule to make > > > > > > newsourcename.c. Stop.". > > > > > > > > > > > > Do you think the following rule (added to the src/Makefile which is > > > > > > soft-linked from every shadow directory) could take care of my > > > > > > problem > > > > > > without undesired side-effects? > > > > > > > > > > > > *: ../$@ > > > > > > ln -sv ../$@ > > > > > > > > > > > > The idea is to create a link if a needed file exist inthe parent > > > > > > (src) > > > > > > directory but not in the current (shadow) directory. Maybe the > > > > > > target > > > > > > sould be made less general to avoid using this rule out of turn. > > > > > > > > > > What happens with "make foo"? Doesn't it execute "ln -sv ../foo" > > > > > then? > > > > > Or say "../foo" does not exist"? Both are very confusing. > > > > > > > > > > Perhaps we can the "ln" line from "make shadow" and add it with a > > > > > "shadowupdate" target: > > > > > > > > > > shadowupdate: > > > > > ln -s ../*.[chm] ../*.in ../*.sh ../*.xs ../*.xbm > > > > > ../gui_gtk_res.xml ../toolcheck ../proto ../libvterm ../vimtutor > > > > > ../gvimtutor ../install-sh ../Make_all.mak . > > > > > > > > > > Probably reports a lot of error for already existing links. > > > > > > > > using -f should force (re-creation) of the link and should not error. > > > > > > Assuming that the user hasn't replaced the link with something else, I > > > suppose it's not a problem to overwrite the link. I would prefer to > > > skip the existing files, but I don't see a flag for "ln" for that. > > > > OK, what about the following, which skips the existing files? > > > > *.[chm] *.cc *.in *.sh *.xs *.xbm *.xml : ../$@ > > ln -sv ../$@ > > AFAIK only GNU make accepts wildcards here, it doesn't work everywhere. > > > (links to directories are created by "make shadow" and don't need to > > be created again; in the case of future directories we don't know what > > they will be, so if new *subdirectories* are created I'll still have > > to link them manually; but that happened much less often recently than > > new .c sources). This won't recreate an already existing link because > > "make" finds the link's date by following the link (otherwise > > incremental compiles wouldn't work). > > > > I intentionally set the -v (--verbose) switch to ln, in order to have > > a trace of the link creation (which is not an everyday event) in the > > log, so an alert user can check that it happened the way it should. > > > > > > > > I can add the shadowupdate rule, but I do wonder how you keep Makefile > > > up-to-date, since that also needs to be changed. > > > > > I keep the src/shadow-*/Makefile up-to-date by replacing (once and for > > all) the *copy* of the src/Makefile created by "make shadow" by a > > *soft link* to ../Makefile. My config arguments are set by means of > > environment variables, not by modifying the Makefile. > > OK, that makes sense. > > -- > hundred-and-one symptoms of being an internet addict: > 136. You decide to stay in a low-paying job teaching just for the > free Internet access. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJkCKXs58Y_WPuinfoyBEGq1-CtfPAfn%2BkaVr_upkKeovtipEg%40mail.gmail.com.
diff --git a/src/Makefile b/src/Makefile --- a/src/Makefile +++ b/src/Makefile @@ -2887,16 +2887,23 @@ shadow: runtime pixmaps ../../testdir/*.ok . # After updating Vim new files may have been created, use this to refresh the # symbolic links in the shadow directory. This isn't guaranteed to catch all # changes, running "make shadow" again might sometimes be needed. shadowupdate: ln -sf $(LINKEDFILES) . +# This tries to automatically link missing sources in an existing shadow directory. +# It isn't guaranteed to catch all changes, sometimes (as when adding a new +# subdirectory of src/ containing sources) it may be necessary to add a new +# link manually. +./*.[chm] ./*.cc ./*.in ./*.sh ./*.xs ./*.xbm ./*.xml : ../$@ + @test -e ./$@ || ln -sv ../$@ + # Link needed for doing "make install" in a shadow directory. runtime: -ln -s ../runtime . # Link needed for doing "make" using GTK in a shadow directory. pixmaps: -ln -s ../pixmaps .
