On Thu, Oct 1, 2015 at 12:55 PM, Freddie Chopin <freddie.cho...@gmail.com> wrote:
> On Thursday 01 of October 2015 10:05:17 Mike Shal wrote: > > Hmm, can you give an example here? I don't understand why you'd want to > > have libsomething.a and then a <libsomething.a> group - after all, an > > archive is really just a group of objects :). I'm curious to see how > you're > > using it! > > First of all the <libsomething.a> group only has one file - libsomething.a > - > and nothing more. > > The problem here is that tup doesn't allow me to specify a file as input > if it > was generated in different directory by a different tupfile. The only way > around that was to use groups. > 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. > I actually had to do the same thing with generated headers used as > order-only > inputs - such use also produces a very similar error message, so I used > groups > too. > 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. 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. > > Building out of the source tree (which is the "root cause" of this error) - > which you probably don't like - can be justified in many ways. Ease to > clean > the whole project is just one of them. The fact that countless .o files > don't > clutter your view of the source hierarchy is another one. Or the fact that > you > can build multiple variants of the same source (for example for different > architectures) at the same time. > 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. > > Or maybe you're asking why I archive objects in my project instead of using > objects directly? If that's the case, then I'm writing an RTOS for > microcontrollers, and in most use-cases you don't have to compile the RTOS > along with your application - all you need are the headers and the archive > with the whole system functionality. > Nope, that's perfectly reasonable :). > > There are more restrictions like this one in tup - for example the fact > that > you cannot use dot-files or dot-folders as input/output (I've wrote about > that > some time ago). > 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 :). I still have a backlog of ~200 mailing list threads to go through :/ -Mike -- -- tup-users mailing list email: tup-users@googlegroups.com unsubscribe: tup-users+unsubscr...@googlegroups.com 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 tup-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
