On Thursday 01 of October 2015 13:10:05 Mike Shal wrote: > Ahh, that makes sense. It should be fairly easy to lift this restriction > for explicit files (like 'libsomething.a'), but I couldn't figure out how > to get it to work with wildcards (like '*.a'), since tup currently expands > the wildcards as it parses them. So there's no guarantee that the Tupfile > that tries to use '*.a' as an input is parsed after another Tupfile > declares ../libs/libsomething.a as an output. I think to do that, wildcards > would have to be somehow expanded after parsing, or maybe even just get > translated to a group internally.
That would probably be a really good idea... Every output of every tup rule would be put in the group with name equal to the file name and the path equal to the real path of the file (so $(TOP)/some/path/to/file.txt would be put to $(TOP/some/path/to/<file.txt> group). Wildcards could then just browse through regular files _AND_ group names in the given path. Every input to the command would also be translated to a group. I think this could reduce the amount of code to maintain - I suspect that a lot of code for group dependencies is similar to the code for regular files. Additionally I think this would allow to support wildcards-that-also-search- subdirectories. For example sth like "$(TOP)/some/*/*.o" would search for all files with .o extension in $(TOP)/some/ path and all of its subfolders - also by just checking regular files _AND_ group names/paths. > I'm not sure if this would work in your situation, but the way I typically > use groups is to put all generated headers in a single group. Something > > like: > : |> generate foo.h |> foo.h $(PROJ_ROOT)/<generated-headers> > > Then all compiler invocations can just declare <generated-headers> as an > input. I did the same, but didn't describe that clearly (; I have only one group with generated headers too (; > Depending on how you use libraries, you can probably do the same > thing: > : |> generate libsomething.a |> ../libs/libsomething.a > > $(PROJ_ROOT)/<archives> > > And then linker commands can list <archives> as an input, and freely read > from any archive in the group. Because of special linking requirements (the library with the RTOS overrides some symbols from the toolchain's libraries) I have to use it inside "-Wl,-- whole-archive ... -Wl,--no-whole-archive". That's why I didn't want a solution that would put all generated archives in the command - I needed a finer control over the files used. And I also like universal solutions, which was probably a bigger reason here (; > Tup should definitely support that better, but it was originally designed > assuming outputs would be written where the Tupfiles are. It's hard to > design a system like that from scratch without some assumptions in place to > simplify things. I know, I still remember that stage and I see how much tup changed since then! > Sorry, I haven't had as much time to work on tup as I had hoped :(. > dot-files/folders have been ignored primarily to skip scanning & tracking > things in .git and .tup, but it ignores all hidden files, because why would > you want to build things that are hidden from the developer? Maybe that's a > dumb idea and you have perfectly good reasons spelled out in the previous > thread :). Well, one of the use cases was to generate a string with git version/commit of the repository - tup has to resort to shell script to do exactly the same thing during its own build procedure... Tup should obviously forbid any interactions with the .tup/ folder, but I think that the rest of folders should be accessible. Anyway - the dot-files/-folders are hidden only in Linux, you can normally see them in Windows (; Regards, FCh -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
