Thread: [A-A-P-develop] Actual libtool support routines
Brought to you by:
vimboss
Menu
▾
▴
a-a-p-develop
|
From: Adriaan de G. <ad...@cs...> - 2003-08-27 20:29:03
Attachments:
libtool.aap
|
Find attached compile and install actions for libtool libraries. I wonder
whether they should be merged into default.aap or left standalone - after
all, not everyone is going to use libtool thingies, and it might expand to
quite some body of code in the end.
--
pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <gr...@kd...>
Key fingerprint = 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE
|
|
From: Bram M. <Br...@mo...> - 2003-08-28 13:30:40
|
Adriaan de Groot wrote: > Find attached compile and install actions for libtool libraries. I wonder > whether they should be merged into default.aap or left standalone - after > all, not everyone is going to use libtool thingies, and it might expand to > quite some body of code in the end. The default.aap recipe is indeed growing bigger all the time. This slows down startup (although it might not be very noticable yet). I'm not sure if libtool support really should be optional, but let's use it as a case. Suppose libtool support turns into a large pile of actions and other stuff, so that we don't want it in default.aap. Then a user would have to specify he wants to use libtool support. The simplest method would be to require something like ":import libtool". We can make a collection of these optional modules. Could this mechanism be automated? Thus as soon as something related to libtool is used, a search for the libtool module is done and it's loaded. This would require making a list of the actions and routes that the module provides, so that Aap knows which module to load. Does this sound too complicated? -- "The amigos also appear to be guilty of not citing the work of others who had gone before them. Even worse, they have a chapter about modeling time and space without making a single reference to Star Trek!" (Scott Ambler, reviewing the UML User Guide) /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html /// |
|
From: Adriaan de G. <ad...@cs...> - 2003-08-28 21:47:33
|
On Thursday 28 August 2003 15:30, you wrote:
> The simplest method would be to require something like ":import libtool".
> We can make a collection of these optional modules.
I'd go for that, with an :import command which would look for libtool.aap
(just like default.aap) in some standard places. You can use :ltlib without
any penalty without importing the module, it's just that AAP will complain
that there is (say) no compile action defined for ltlibobjects when it comes
time to build something.
:import should work a lot like :include, but only search in system places.
> Could this mechanism be automated? Thus as soon as something related to
> Does this sound too complicated?
It does; in particular since you'd have to recognize things like LIBADD (which
might be a libtool thing) and every other subtlety of libtoolism. Perhaps
using :ltlib should automatically load the libtool module, but in general I'd
say that the penalty of having to do
:import libtool
in recipes for libtool is small; especially since other build weirdnesses
might have a similar structure (:import distcc, anyone?),
--
pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <gr...@kd...>
Key fingerprint = 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE
|
|
From: Bram M. <Br...@mo...> - 2003-08-29 10:28:33
|
Adriaan de Groot wrote:
> On Thursday 28 August 2003 15:30, you wrote:
> > The simplest method would be to require something like ":import libtool".
> > We can make a collection of these optional modules.
>
> I'd go for that, with an :import command which would look for libtool.aap
> (just like default.aap) in some standard places. You can use :ltlib without
> any penalty without importing the module, it's just that AAP will complain
> that there is (say) no compile action defined for ltlibobjects when it comes
> time to build something.
>
> :import should work a lot like :include, but only search in system places.
It is starting to look like a good idea. Thinking ahead for the future
with hundreds of modules available (well, _far_ future), do we need
to do something with scopes for imported modules? The ":include"
command uses the current scope of the recipe, perhaps for ":import" the
imported module should have its own scope, so that it can have local
variables. This would be important when doing the ":import" from
several recipes in a recipe tree. You wouldn't want to libtool module
to use the scope of several recipes, do you?
> > Could this mechanism be automated? Thus as soon as something related to
> > Does this sound too complicated?
>
> It does; in particular since you'd have to recognize things like
> LIBADD (which might be a libtool thing) and every other subtlety of
> libtoolism. Perhaps using :ltlib should automatically load the libtool
> module, but in general I'd say that the penalty of having to do
>
> :import libtool
>
> in recipes for libtool is small; especially since other build weirdnesses
> might have a similar structure (:import distcc, anyone?),
Let's not make it automagical. The ":ltlib" command is a high-level
command for which it is logical that you always need the libtool module,
thus automatically doing a ":import libtool" sounds acceptable. But
importing a libtool module when a "ltobject" filetype is used somewhere
is too much magic.
Are you going to make that libtool module? Then we also need the
":import" command. Earn a few more Zimbu award points!
--
hundred-and-one symptoms of being an internet addict:
257. Your "hundred-and-one" lists include well over 101 items, since you
automatically interpret all numbers in hexadecimal notation.
(hex 101 = decimal 257)
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
|
|
From: Adriaan de G. <ad...@cs...> - 2003-08-31 20:17:03
|
On Friday 29 August 2003 12:28, Bram Moolenaar wrote:
> Adriaan de Groot wrote:
> > :import should work a lot like :include, but only search in system
> > : places.
>
> variables. This would be important when doing the ":import" from
> several recipes in a recipe tree. You wouldn't want to libtool module
> to use the scope of several recipes, do you?
:import should be like :include {once} with no path component. It should
search for the module in some standard places (and no others). The module
should have its own scope (or possibly a shared _module scope if that's too
hard to implement) faily high up in the rpstack.
> Are you going to make that libtool module? Then we also need the
> ":import" command. Earn a few more Zimbu award points!
The libtool module I've already sent in, though it might need some more
polishing and documenting. I'll do :import.
--
pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <gr...@kd...>
Key fingerprint = 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE
|
|
From: Bram M. <Br...@mo...> - 2003-08-31 21:16:26
|
Adriaan de Groot wrote:
> On Friday 29 August 2003 12:28, Bram Moolenaar wrote:
> > Adriaan de Groot wrote:
> > > :import should work a lot like :include, but only search in system
> > > : places.
> >
> > variables. This would be important when doing the ":import" from
> > several recipes in a recipe tree. You wouldn't want to libtool module
> > to use the scope of several recipes, do you?
>
> :import should be like :include {once} with no path component. It should
> search for the module in some standard places (and no others). The module
> should have its own scope (or possibly a shared _module scope if that's too
> hard to implement) faily high up in the rpstack.
It's probably a good idea to give each ":import"'ed module its own
scope, so that it doesn't need to worry about names of variables used
elsewhere. But I think this scope doesn't need to be exposed to other
recipes. If some things need to be available elsewhere the module can
set values in the toplevel scope. If some things need to be shared with
other modules (even though that sounds unlikely at this time) a new
scope can be created for it.
This is also relatively easy to implement, because the scope of the
imported recipe doesn't need to be added to the stack of scopes.
> > Are you going to make that libtool module? Then we also need the
> > ":import" command. Earn a few more Zimbu award points!
>
> The libtool module I've already sent in, though it might need some more
> polishing and documenting. I'll do :import.
Great. Then I can continue making it easier to download and install Aap
and Agide. "aap --install agide" is now almost working.
--
Microsoft: "Windows NT 4.0 now has the same user-interface as Windows 95"
Windows 95: "Press CTRL-ALT-DEL to reboot"
Windows NT 4.0: "Press CTRL-ALT-DEL to login"
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
|
Thanks for helping keep SourceForge clean.
X