Thread: [A-A-P-develop] More on Actions, routes and builders in general
Brought to you by:
vimboss
From: Bram M. <Br...@mo...> - 2004-06-12 15:59:39
|
Previously I discussed whether we should add "builders" to Aap. After looking deeper into this issue I came to the conclusion that Aap actions almost did what was needed. Expanding actions to behave like a builder is relatively simple and, perhaps more important, backwards compatible. I have now implemented a new way to define an action, using the Python function define_action(). This is simpler to use than action_add(), which was previously used in tools. And allows for more features. Docs are available here: http://www.a-a-p.org/exec/ref-python.html#python-define-action One of the new things about actions is that an action can be marked as a "primary" action. A primary action is the first choice for turning its input filetypes into the supported output filetypes. When using a command like ":program" Aap can now search for actions that do the required compiling and/or building. As a result most ":route" commands can be omitted. Note that a tool-specific compile action should not be primary, it is invoked indirectly from the default compile action. The $C_COMPILE_ACTION variable is used for this, just like before. More explanations in the documentation. I have already updated the default.aap recipe to use define_action() where needed. I also updated the gcc tool and the libtool module. But most other tools still need to be done. This was quite a big change. Please verify that Aap still works properly with your recipe. Especially with C++, libtool and other non-obvious building. When it works, please have a look at the tools you use and if they can profit from using define_action(). Especially for defining more supported filetypes. For example, if the build action supports a "def" type, then ":program" should be able to recognize that and handle it properly. One decision I would like to mention: I previously thought a Builder could consist of multiple steps. E.g., to turn a lex file in to C and then into an object file. I now think it is simpler to define the separate steps as primary actions. Aap will be able to figure out that two steps in sequence need to be used. I tested this with a lex file, but not yet with something more complicated (more than two steps). The new version has been checked in to CVS. Let's hear it when something doesn't work right! -- hundred-and-one symptoms of being an internet addict: 98. The Alta Vista administrators ask you what sites are missing in their index files. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-14 20:56:06
|
In the d.aap module, the only difference between the object,libobject and dllobject out types were their build attribute. What I did there, was to have an action d_compile that did the main work, and three compiles; one for each out type that only added the buildaction attribute before executing d_compile. Do I still have to do it this way, or can I find out what the outtype of action should be ($OUTTYPE) so I can add the correct buildaction based on that variable? Something like: @if OUTTYPE == "libobject": :attr {buildaction = buildlib} $target Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-15 09:13:08
|
Lars Ivar Igesund wrote: > In the d.aap module, the only difference between the object,libobject > and dllobject out types were their build attribute. What I did there, > was to have an action d_compile that did the main work, and three > compiles; one for each out type that only added the buildaction > attribute before executing d_compile. Do I still have to do it this way, > or can I find out what the outtype of action should be ($OUTTYPE) so I > can add the correct buildaction based on that variable? > > Something like: > > @if OUTTYPE == "libobject": > :attr {buildaction = buildlib} $target We don't have $OUTTYPE. I think this is just a small optimization, not really worth changing. Looking at the d module I notice that the d_compile, d_build, d_builddll and d_buildlib actions use ":do" to redirect the work to another action. Those should be rewritten to use define_action(). It's strange that d_buildlib doesn't do anything when D_BUILDLIB_ACTION is not set. Not even an error. -- hundred-and-one symptoms of being an internet addict: 122. You ask if the Netaholics Anonymous t-shirt you ordered can be sent to you via e-mail. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-17 17:12:03
|
Bram Moolenaar wrote: > Lars Ivar Igesund wrote: > > >>In the d.aap module, the only difference between the object,libobject >>and dllobject out types were their build attribute. What I did there, >>was to have an action d_compile that did the main work, and three >>compiles; one for each out type that only added the buildaction >>attribute before executing d_compile. Do I still have to do it this way, >>or can I find out what the outtype of action should be ($OUTTYPE) so I >>can add the correct buildaction based on that variable? >> >>Something like: >> >>@if OUTTYPE == "libobject": >> :attr {buildaction = buildlib} $target > > > We don't have $OUTTYPE. I think this is just a small optimization, not > really worth changing. > > Looking at the d module I notice that the d_compile, d_build, d_builddll > and d_buildlib actions use ":do" to redirect the work to another action. > Those should be rewritten to use define_action(). I didn't get what "those" pointed to, but; The reason why it was done this way, was mostly to don't need the full compile code in all three actions. So I tried with three actions (one for each outtype) and no redirection. As I understand it, all those three should be primary actions, all with "d" as intype and differing outtypes. This leads to trouble. Only the last defined action seems to be remembered. First, the last action was the one with libobject as outtype. In a recipe with a :lib and a :program, the lib built fine while the program crashed with the message: Error in recipe "define_action(build) from libobject,object,default to default" line 474: No commands defined for d_buildlib program from object Then i moved the define_action calls, making the one with object as outtype the last. Then I got the following message on the lib target: Error in recipe "define_action(buildlib) from libobject,object,default to default" line 474: No commands defined for d_build lib from libobject > > It's strange that d_buildlib doesn't do anything when D_BUILDLIB_ACTION > is not set. Not even an error. > An unintended omission. My new version don't have any default stuff happening if no tool has been loaded. It makes the default recipe to dependant on one compiler before the compiler landscape is stabilized, while it also becomes a hell to keep it up to date (it's already in a tool). Instead it prints a message about the supported tool chains that can be installed. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-17 19:29:02
|
Lars Ivar Igesund wrote: > > Looking at the d module I notice that the d_compile, d_build, d_builddll > > and d_buildlib actions use ":do" to redirect the work to another action. > > Those should be rewritten to use define_action(). > > I didn't get what "those" pointed to, but; The reason why it was done > this way, was mostly to don't need the full compile code in all three > actions. So I tried with three actions (one for each outtype) and no > redirection. As I understand it, all those three should be primary > actions, all with "d" as intype and differing outtypes. Be careful to only make actions "primary" when they are always to be used for turning its input filetypes into its output filetypes. Thus one would be "d" to "object,default", another "d" to "libobject" and the third "d" to "dllobject". These are in the d module, the actions in the dmd tool can't be primary actions, they are invoked indirectly by the module. > This leads to trouble. Only the last defined action seems to be > remembered. First, the last action was the one with libobject as > outtype. In a recipe with a :lib and a :program, the lib built fine > while the program crashed with the message: > > Error in recipe "define_action(build) from libobject,object,default to > default" line 474: No commands defined for d_buildlib program from object > > Then i moved the define_action calls, making the one with object as > outtype the last. Then I got the following message on the lib target: > > Error in recipe "define_action(buildlib) from libobject,object,default > to default" line 474: No commands defined for d_build lib from libobject Strange. I would think you did something wrong in the way you defined the actions. They are all added in a list, they don't overwrite each other. I guess you are using BUILDLIB_ACTION or adding a {buildaction} attribute to the object files. Then the "buildlib" action invokes that action. Don't see how that can go wrong. I can't guess what is wrong. Can you show me the code? -- hundred-and-one symptoms of being an internet addict: 170. You introduce your wife as "my_lady@home.wife" and refer to your children as "forked processes." /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-19 14:34:22
|
Bram Moolenaar wrote: > Be careful to only make actions "primary" when they are always to be > used for turning its input filetypes into its output filetypes. Thus one > would be "d" to "object,default", another "d" to "libobject" and the > third "d" to "dllobject". These are in the d module, the actions in the > dmd tool can't be primary actions, they are invoked indirectly by the > module. That's the way it is. > I can't guess what is wrong. Can you show me the code? (d.aap and dmd.py are attached.) It is quite possible that something is wrong in my code somewhere, but as I said before, if I want to build a program only, it works if the compile to object,default is the last to be defined. I have detected why this happens (although I don't know if it is intended or not): The executive use the find_action to find the correct action to use. find_action finds the last action added that satisfies both the intype and outtype needed. To find out which types are supported by an action, get_in_types and get_out_types are used. The problem exist for both of them, but in this case it is only a problem with get_out_types. get_out_types checks if there is an action to defer the work to (and there is in this case; compile_dmd). get_out_types then use get_ftypes and it is here the real trouble is created. get_ftypes adds all the outtypes supported by all the compile_dmd actions to the list of outtypes to be returned, and in total all the compile_dmd actions support all three outtypes. This leads to the fact that all three primary actions satisfies the if in find_action and thus the last defined is returned as the action to use even though it might not _really_ support the outtype requested. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-19 17:58:20
|
Lars Ivar Igesund wrote: > Bram Moolenaar wrote: > > Be careful to only make actions "primary" when they are always to be > > used for turning its input filetypes into its output filetypes. Thus one > > would be "d" to "object,default", another "d" to "libobject" and the > > third "d" to "dllobject". These are in the d module, the actions in the > > dmd tool can't be primary actions, they are invoked indirectly by the > > module. > > That's the way it is. > > > I can't guess what is wrong. Can you show me the code? > > (d.aap and dmd.py are attached.) They were not attached, thus I have to do a bit of guessing. > It is quite possible that something is wrong in my code somewhere, but > as I said before, if I want to build a program only, it works if the > compile to object,default is the last to be defined. I have detected why > this happens (although I don't know if it is intended or not): > > The executive use the find_action to find the correct action to use. > find_action finds the last action added that satisfies both the intype > and outtype needed. To find out which types are supported by an action, > get_in_types and get_out_types are used. The problem exist for both of > them, but in this case it is only a problem with get_out_types. > get_out_types checks if there is an action to defer the work to (and > there is in this case; compile_dmd). get_out_types then use get_ftypes > and it is here the real trouble is created. get_ftypes adds all the > outtypes supported by all the compile_dmd actions to the list of > outtypes to be returned, and in total all the compile_dmd actions > support all three outtypes. This leads to the fact that all three > primary actions satisfies the if in find_action and thus the last > defined is returned as the action to use even though it might not > _really_ support the outtype requested. There currently is no restriction in the input types for the desired output, and the other way around. But from your description that doesn't appear to be the problem. You say all three primary actions defer the work to a "compile_dmd" action. Then isn't it so that each action can accept the work and defer it to "compile_dmd"? Where does this go wrong? Adding a restriction in the output types that only one input type is used wouldn't help, since the input is always a "d" file. I'll look into the extra check for the combination of input and output type in one action, but I'm not sure if that will help for your problem. -- Your mouse has moved. Windows must be restarted for the change to take effect. Reboot now? /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-19 19:07:00
|
Bram Moolenaar wrote: > They were not attached, thus I have to do a bit of guessing. Sorry. > You say all three primary actions defer the work to a "compile_dmd" > action. Then isn't it so that each action can accept the work and defer > it to "compile_dmd"? Where does this go wrong? Ah, my description of the problem were somewhat wrong. There is only 1 compile_dmd action that can output all three types of object. But there are three primary compile actions in d.aap. These support only one output type each (because they add the correct buildaction attribute). But when the outtypes are checked, it looks at the compile_dmd, and thus it isn't able to distinguish between the primary actions. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-20 11:18:46
|
Lars Ivar Igesund wrote: > > You say all three primary actions defer the work to a "compile_dmd" > > action. Then isn't it so that each action can accept the work and defer > > it to "compile_dmd"? Where does this go wrong? > > Ah, my description of the problem were somewhat wrong. There is only 1 > compile_dmd action that can output all three types of object. But there > are three primary compile actions in d.aap. These support only one > output type each (because they add the correct buildaction attribute). > But when the outtypes are checked, it looks at the compile_dmd, and thus > it isn't able to distinguish between the primary actions. OK, now I understand the situation. When the primary action defers the work to another action, this currently has the effect that the primary action supports the input and output types of the action that the work is deferred to. In the situation you mention this shouldn't happen, the action doesn't really support more output types. The simplest solution is to define these actions in the old way, with ":action". I don't know if any of the other extra features of using define_action() is desired. If that is so, then defining get_out_types() yourself would work. -- hundred-and-one symptoms of being an internet addict: 216. Your pet rock leaves home. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-20 12:21:58
|
Bram Moolenaar wrote: > I don't know if any of the other extra features of using > define_action() is desired. If that is so, then defining > get_out_types() yourself would work. > Well, it worked as it should before, I think, but I believe that at some time it might be necessary to be able to support more intypes (resource files are a good guess) and I had the understanding that that would be best through using define_action()? And where should I define get_out_types() myself? Anyway, I think that it is a bug the way it is now (since the same actions worked when using :action). The solution (IMO) would be to check the types of the primary action with the types requested by the recipe and then make sure that the action that do the real work supports at least the same types as the primary action. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-20 14:22:42
|
Lars Ivar Igesund wrote: > Bram Moolenaar wrote: > > > I don't know if any of the other extra features of using > > define_action() is desired. If that is so, then defining > > get_out_types() yourself would work. > > > > Well, it worked as it should before, I think, but I believe that at some > time it might be necessary to be able to support more intypes (resource > files are a good guess) and I had the understanding that that would be > best through using define_action()? If the input or output types that an action supports are not static, but depend on settings or tools available, then define_action() should be used. For static types ":action" is probably sufficient. > And where should I define get_out_types() myself? There is a simplistic example in the docs (ref-python). However, I am not pleased with this method. Mainly because the function you define is not part of the class, thus you can't use "self". Perhaps there is another way to overrule the function? If not, then subclassing Action would be required. I try avoiding that, because this means exposing internals. > Anyway, I think that it is a bug the way it is now (since the same > actions worked when using :action). The solution (IMO) would be to check > the types of the primary action with the types requested by the recipe > and then make sure that the action that do the real work supports at > least the same types as the primary action. But that already happens. The compile_dmd action that is invoked does support the output type. The problem is that Aap doesn't know that the type of the primary action should be used, and not the type of the action the work is deferred to. The whole point of doing this defer stuff was that a build action can support more types when the work is deferred to another action. Thus normally a "build" action would only support object files, on some systems it can additionally support "resource" files, or whatever the linker accepts. Thus when defining the action you must make clear to Aap what input and output types are supported. The get_in_types() and get_out_types() functions are to be defined for that. -- hundred-and-one symptoms of being an internet addict: 221. Your wife melts your keyboard in the oven. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-20 14:46:43
|
Ok, I understand most of the issues now. I don't like the get_out_types way myself, so what I would prefer is the possibility to query the outtype wanted in the primary action (as I asked previosly). Then I could have only one primary action that supported all three outtypes and new intypes could still be supported through a defer action. It also has the added effect that it shortens my code :) Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-20 19:53:15
|
Lars Ivar Igesund wrote: > Ok, I understand most of the issues now. I don't like the get_out_types > way myself, so what I would prefer is the possibility to query the > outtype wanted in the primary action (as I asked previosly). Then I > could have only one primary action that supported all three outtypes and > new intypes could still be supported through a defer action. It also has > the added effect that it shortens my code :) You already get these: $filetype is the input type, $targettype is the output type. -- hundred-and-one symptoms of being an internet addict: 226. You sit down at the computer right after dinner and your spouse says "See you in the morning." /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Lars I. I. <lar...@ig...> - 2004-06-21 11:10:48
|
Bram Moolenaar wrote: > You already get these: $filetype is the input type, $targettype is the > output type. So why didn't you say so the last time I asked ;) Anyway, it now works like a charm. Attached is the updated module and tool. :program, :dll and :lib work as well as before. Diffs attached. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2004-06-21 12:07:17
|
Lars Ivar Igesund wrote: > > You already get these: $filetype is the input type, $targettype is the > > output type. > > So why didn't you say so the last time I asked ;) To make you read the docs :-). > Anyway, it now works like a charm. Attached is the updated module and > tool. :program, :dll and :lib work as well as before. > > Diffs attached. Thanks, I'll include this and check a new version into CVS. -- hundred-and-one symptoms of being an internet addict: 236. You start saving URL's in your digital watch. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |