Re: [tup] Multiple output groups?

[Mike Shal]

On Wed, Sep 30, 2015 at 4:28 PM, Freddie Chopin 
wrote:

> > Yeah, they can be handy :). Part of me thinks that we could just use
> groups
> > for inputs/outputs and not list any files manually. Though we'd also have
> > to fix the explicit-listing-of-output-files issue for that to work.
>
> This is something (partially) close to what I've done in my project. If I
> archive multiple objects to an archive libsomething.a in output/some/path/
> then I also put this file in $(TOP)/output/some/path/. By
> passing such group to a function (that generates some rule - for example
> to do
> the linking) I can get the type of the file from the extension in the group
> name (".a") and I can get the path from the whole string. I actually pass
> only
> the real path to file to the function, which internally is converted to
> proper
> group. Lua parser gives you many possibilities, but because not many people
> use it (noone? (; ) most of the "proper ways of doing something" still
> wait to
> be discovered (;
>

Hmm, can you give an example here? I don't understand why you'd want to
have libsomething.a and then a  group - after all, an
archive is really just a group of objects :). I'm curious to see how you're
using it!

-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.

Re: [tup] Multiple output groups?

[Mike Shal]

On Thu, Oct 1, 2015 at 12:55 PM, Freddie Chopin 
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  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  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)/

Then all compiler invocations can just declare  as an
input. Depending on how you use libraries, you can probably do the same
thing:

: |> generate libsomething.a |> ../libs/libsomething.a
$(PROJ_ROOT)/

And then linker commands can list  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.

Re: [tup] Multiple output groups?

[Freddie Chopin]

Hello Mike!

On Tuesday 29 of September 2015 16:34:04 Mike Shal wrote:
> I don't think there are any major technical reasons why it couldn't be
> implemented. There was an issue filed on github a while back for this that
> has some more details: https://github.com/gittup/tup/issues/166

Good to know that there are no technical limitations to implementing such 
thing. For now I've solved my problem without need for multiple groups, but 
the solution with multiple groups would look better and be more universal (;

If anyone is interested in what I've done, you can check last few commits that 
mention "tup build", or any tup file (Tuprules.lua, Tupfile.lua) - 
https://github.com/DISTORTEC/distortos

Generally I've managed to (ab)use groups to pass any number of single files 
with their path (archives, generated linker scripts) or any number of normal 
groups (compiled objects) to the function that does linking (link()). All of 
that uses lua's varargs.

> Yeah, they can be handy :). Part of me thinks that we could just use groups
> for inputs/outputs and not list any files manually. Though we'd also have
> to fix the explicit-listing-of-output-files issue for that to work.

This is something (partially) close to what I've done in my project. If I 
archive multiple objects to an archive libsomething.a in output/some/path/ 
then I also put this file in $(TOP)/output/some/path/. By 
passing such group to a function (that generates some rule - for example to do 
the linking) I can get the type of the file from the extension in the group 
name (".a") and I can get the path from the whole string. I actually pass only 
the real path to file to the function, which internally is converted to proper 
group. Lua parser gives you many possibilities, but because not many people 
use it (noone? (; ) most of the "proper ways of doing something" still wait to 
be discovered (;

Regards,
FCh

-- 
-- 
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.