Thread: [A-A-P-develop] Language module support modified
Brought to you by:
vimboss
From: Bram M. <Br...@mo...> - 2003-09-30 01:05:42
|
Because of the discussions about importing modules recently I have made a few changes: - The search order is now first the home directory, then /usr/local, then the Aap directory. The first module found is used. - This search order is now also used for tools, thus you can put your own tools in ~/.aap/tools/. I haven't tested this much yet! - I added a lot of documentation, although it's not finished yet (ran into a few bugs that had to be fixed). - Renamed the "dlang" module to the "d" module. - The module scope name is now "m_name" for module "name". This is in Aap version 1.034, available from CVS now. Please give this a good bit of testing before I release the .zip file. Adriaan, perhaps we should move the libtool stuff from default.aap to a "libtool" module? -- Microsoft is to software what McDonalds is to gourmet cooking /// 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: Aschwin M. <as...@ma...> - 2003-09-30 03:54:16
|
On Mon, 29 Sep 2003, Bram Moolenaar wrote: > Because of the discussions about importing modules recently I have made > a few changes: > > - The search order is now first the home directory, then /usr/local, > then the Aap directory. The first module found is used. Why /usr/local? This is not a portable location. How this this work on "the other OS"? > - This search order is now also used for tools, thus you can put your > own tools in ~/.aap/tools/. I haven't tested this much yet! Great. > - I added a lot of documentation, although it's not finished yet (ran > into a few bugs that had to be fixed). Even more important. > - Renamed the "dlang" module to the "d" module. > > - The module scope name is now "m_name" for module "name". > > This is in Aap version 1.034, available from CVS now. Please give this > a good bit of testing before I release the .zip file. > > Adriaan, perhaps we should move the libtool stuff from default.aap to a > "libtool" module? Have fun, Aschwin Marsman -- as...@ma... http://www.marsman.org |
From: Bram M. <Br...@mo...> - 2003-09-30 08:55:33
|
Aschwin Marsman wrote: > On Mon, 29 Sep 2003, Bram Moolenaar wrote: > > > Because of the discussions about importing modules recently I have made > > a few changes: > > > > - The search order is now first the home directory, then /usr/local, > > then the Aap directory. The first module found is used. > > Why /usr/local? This is not a portable location. How this this work > on "the other OS"? For me "/usr/local/..." is _the_ standard location optional SW for Unix systems. But some guys decided to use another location... I suppose we would need to add a variable that holds the name of this directory. Something like $AAP_SYS_DIR? The default would be "/usr/local/share/aap". -- hundred-and-one symptoms of being an internet addict: 45. You buy a Captain Kirk chair with a built-in keyboard and mouse. /// 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-09-30 07:59:26
|
On Mon, 29 Sep 2003, Bram Moolenaar wrote: > - The search order is now first the home directory, then /usr/local, > then the Aap directory. The first module found is used. Like someone else already pointed out, /usr/local is rather unportable. I presume you mean "the OS-specific place for "extra software"". > - The module scope name is now "m_name" for module "name". Cool. > Adriaan, perhaps we should move the libtool stuff from default.aap to a > "libtool" module? Yes, it definitely needs to be removed from there. I've sent a couple of versions of the libtool module to the list before, I'll send in the current version (which tries a little harder to find a libtool executable if the user doesn't specify one, and which knows about version numbers) this evening. -- Adriaan de Groot ad...@cs... Kamer A6020 024-3652272 GPG Key Fingerprint 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE http://www.cs.kun.nl/~adridg/research/ |
From: Bram M. <Br...@mo...> - 2003-09-30 09:06:02
|
Adriaan de Groot wrote: > On Mon, 29 Sep 2003, Bram Moolenaar wrote: > > - The search order is now first the home directory, then /usr/local, > > then the Aap directory. The first module found is used. > > Like someone else already pointed out, /usr/local is rather > unportable. I presume you mean "the OS-specific place for "extra > software"". And how would Aap find out where that is? I could add a variable in default.aap, but I found one place where the /usr/local/... directory is used without reading it: filetype detection. Perhaps this is something that must be done when installing Aap? > > Adriaan, perhaps we should move the libtool stuff from default.aap to a > > "libtool" module? > > Yes, it definitely needs to be removed from there. I've sent a couple of > versions of the libtool module to the list before, I'll send in the > current version (which tries a little harder to find a libtool executable > if the user doesn't specify one, and which knows about version numbers) > this evening. Very good. Perhaps a few things can then be removed from default.aap? -- hundred-and-one symptoms of being an internet addict: 48. You get a tatoo that says "This body best viewed with Netscape 3.1 or higher." /// 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-09-30 09:48:36
|
On Tue, 30 Sep 2003, Bram Moolenaar wrote: > > Like someone else already pointed out, /usr/local is rather > > unportable. I presume you mean "the OS-specific place for "extra > > software"". > > And how would Aap find out where that is? > > I could add a variable in default.aap, but I found one place where the > /usr/local/... directory is used without reading it: filetype detection. > Perhaps this is something that must be done when installing Aap? if os == "posix": if test -d "/opt": os_local_dir="/opt" else: os_local_dir="/usr/local" else: os_local_dir="C:/WINDOWS/SYSTEM" That's a start, isn't it? -- Adriaan de Groot ad...@cs... Kamer A6020 024-3652272 GPG Key Fingerprint 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE http://www.cs.kun.nl/~adridg/research/ |
From: Aschwin M. <as...@ma...> - 2003-09-30 10:30:21
|
Quoting Adriaan de Groot <ad...@cs...>: > On Tue, 30 Sep 2003, Bram Moolenaar wrote: > > > Like someone else already pointed out, /usr/local is rather > > > unportable. I presume you mean "the OS-specific place for "extra > > > software"". > > > > And how would Aap find out where that is? > > > > I could add a variable in default.aap, but I found one place where the > > /usr/local/... directory is used without reading it: filetype detection. > > Perhaps this is something that must be done when installing Aap? > if os == "posix": > if test -d "/opt": > os_local_dir="/opt" > else: > os_local_dir="/usr/local" > else: > os_local_dir="C:/WINDOWS/SYSTEM" > > That's a start, isn't it? This is a start, although it's administrator specific if he prefers /opt i.s.o. /usr/local. So we can choose a default, but it should be possible for the user to override this choice, e.g. with an environment variable. Below is a long explanation from the (Linux) Filesystem Hierarchy Standard about the use of /usr/local & /opt. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. /+opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package. Requirements The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. Programs to be invoked by users must be located in the directory /opt/<package>/bin. If the package includes UNIX manual pages, they must be located in /opt/<package>/man and the same substructure as /usr/share/man must be used. Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information. Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information. No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev. Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator. BEGIN RATIONALE The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt. The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software. END RATIONALE Kind regards, Aschwin Marsman -- http://www.marsman.org as...@ma... |
From: Bram M. <Br...@mo...> - 2003-09-30 11:08:24
|
Aschwin Marsman wrote: > Quoting Adriaan de Groot <ad...@cs...>: > > On Tue, 30 Sep 2003, Bram Moolenaar wrote: > > > > Like someone else already pointed out, /usr/local is rather > > > > unportable. I presume you mean "the OS-specific place for "extra > > > > software"". > > > > > > And how would Aap find out where that is? > > > > > > I could add a variable in default.aap, but I found one place where the > > > /usr/local/... directory is used without reading it: filetype detection. > > > Perhaps this is something that must be done when installing Aap? > > > if os == "posix": > > if test -d "/opt": > > os_local_dir="/opt" > > else: > > os_local_dir="/usr/local" > > else: > > os_local_dir="C:/WINDOWS/SYSTEM" > > > > That's a start, isn't it? > > This is a start, although it's administrator specific if he > prefers /opt i.s.o. /usr/local. So we can choose a default, > but it should be possible for the user to override this choice, > e.g. with an environment variable. > > Below is a long explanation from the (Linux) Filesystem Hierarchy Standard > about the use of /usr/local & /opt. From this I understand that "/opt/aap" would hold the installed Aap program. Thus it contains the installed modules and tools, not the ones that a system administrator adds for his system. Also, suppose that a Linux distribution decides to include Aap in the base system (one can dream :-), isn't /usr/local/share the appropriate place to put additional tools and modules? -- Never go to the toilet in a paperless office. /// 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: Johan S. <jo...@sv...> - 2003-09-30 11:27:26
|
* Sep 30 13:10 Bram Moolenaar <Br...@mo...>: > > Aschwin Marsman wrote: > > > Quoting Adriaan de Groot <ad...@cs...>: > > > On Tue, 30 Sep 2003, Bram Moolenaar wrote: > > > > > Like someone else already pointed out, /usr/local is rather > > > > > unportable. I presume you mean "the OS-specific place for "extra > > > > > software"". > > > > > > > > And how would Aap find out where that is? > > > > > > > > I could add a variable in default.aap, but I found one place where the > > > > /usr/local/... directory is used without reading it: filetype detection. > > > > Perhaps this is something that must be done when installing Aap? > > > > > if os == "posix": > > > if test -d "/opt": > > > os_local_dir="/opt" > > > else: > > > os_local_dir="/usr/local" > > > else: > > > os_local_dir="C:/WINDOWS/SYSTEM" > > > > > > That's a start, isn't it? > > > > This is a start, although it's administrator specific if he > > prefers /opt i.s.o. /usr/local. So we can choose a default, > > but it should be possible for the user to override this choice, > > e.g. with an environment variable. > > > > Below is a long explanation from the (Linux) Filesystem Hierarchy Standard > > about the use of /usr/local & /opt. > > >From this I understand that "/opt/aap" would hold the installed Aap > program. Thus it contains the installed modules and tools, not the ones > that a system administrator adds for his system. > > Also, suppose that a Linux distribution decides to include Aap in the > base system (one can dream :-), isn't /usr/local/share the appropriate > place to put additional tools and modules? I think this will differ depending on the distribution. Atleast on Debian I think it would be placed in /usr/share while others would place it in /usr/local/share. -- Johan Svedberg, jo...@sv..., http://johan.svedberg.pp.se/ |
From: Bram M. <Br...@mo...> - 2003-09-30 10:52:46
|
Adriaan de Groot wrote: > On Tue, 30 Sep 2003, Bram Moolenaar wrote: > > > Like someone else already pointed out, /usr/local is rather > > > unportable. I presume you mean "the OS-specific place for "extra > > > software"". > > > > And how would Aap find out where that is? > > > > I could add a variable in default.aap, but I found one place where the > > /usr/local/... directory is used without reading it: filetype detection. > > Perhaps this is something that must be done when installing Aap? > > > if os == "posix": > if test -d "/opt": > os_local_dir="/opt" > else: > os_local_dir="/usr/local" > else: > os_local_dir="C:/WINDOWS/SYSTEM" > > That's a start, isn't it? It is a start. Does "/opt" have preference above "/user/local", when both exist? You only mention the start of the path. The rest can also be different. Are "/opt/share/aap" and "/usr/local/share/aap" the best defaults? For MS-Windows I think the "official" location is something like "C:/Documents and Settings/All Users/Application Data/Aap". And it's different depending on the used language... -- CVS sux, men don't like commitment /// 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: Lars I. I. <lar...@ig...> - 2003-09-30 09:32:31
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > - I added a lot of documentation, although it's not finished yet (ran > into a few bugs that had to be fixed). Looks good, although available modules (and tools I suppose) IMHO should be easier to come over. Maybe the list of tools and modules should be present somewhere in th Reference Manual? In addition, variables like DFLAGS and DLINKFLAGS should be present somewhere in the documentation, probably under the d module. I can look at it in the next few days, if I'm given a hint to where I should put it. > > - Renamed the "dlang" module to the "d" module. > > - The module scope name is now "m_name" for module "name". > > This is in Aap version 1.034, available from CVS now. Please give this > a good bit of testing before I release the .zip file. This seems to work for me still. I'm trying to build one of the bigger D projects with aap (make has been used until now), and when I succeed, I will announce it to the D community. (At the moment I'm running into what seems like a compiler bug.) Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-09-30 10:52:50
|
Lars Ivar Igesund wrote: > > - I added a lot of documentation, although it's not finished yet (ran > > into a few bugs that had to be fixed). > > Looks good, although available modules (and tools I suppose) > IMHO should be easier to come over. Maybe the list of tools and > modules should be present somewhere in th Reference Manual? The list of modules can be moved to the reference manual. I suppose that is where most people would look for it. I'll add a chapter after "filetype detection". It's very short right now, but should grow over time. > In addition, variables like DFLAGS and DLINKFLAGS should > be present somewhere in the documentation, probably under the > d module. I can look at it in the next few days, if I'm given a hint to > where I should put it. It would be very good if you can write down those things that a user of the "D" language would like to know. > > - Renamed the "dlang" module to the "d" module. > > > > - The module scope name is now "m_name" for module "name". > > > > This is in Aap version 1.034, available from CVS now. Please give this > > a good bit of testing before I release the .zip file. > > This seems to work for me still. I'm trying to build one of the > bigger D projects with aap (make has been used until now), and > when I succeed, I will announce it to the D community. (At the > moment I'm running into what seems like a compiler bug.) Good. Please do wait until it's stable enough and I have made a .zip file available with all the D support included. Otherwise D users might run into problems too quick and become discouraged. -- hundred-and-one symptoms of being an internet addict: 50. The last girl you picked up was only a jpeg. /// 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: Lars I. I. <lar...@ig...> - 2003-10-01 08:31:10
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > It would be very good if you can write down those things that a user of > the "D" language would like to know. Ok, I've made some additions to ref-modules.sgml, attached in moddoc.diff. (I don't know if the syntax is correct or if it will look well, but at least the information should be there.) I have also made some additions/changes to the compile command used. The user can now specify the argument variables DFLAGS, DLINKFLAGS, DDEBUG, DOPTIMIZE and DVERSION. Except for the DLINKFLAGS, all of the arguments can in theory be put into the DFLAGS variable, but the rationale is to make it easier for the user to see what goes where and that the D language has the possibility to specify lots of debug and version flags that decide which parts of the code to compile (a preprocessor replacement). These changes can be found in d.diff and dmd.diff Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-01 10:21:32
|
Lars Ivar Igesund wrote: > > It would be very good if you can write down those things that a user of > > the "D" language would like to know. > > Ok, I've made some additions to ref-modules.sgml, attached in > moddoc.diff. (I don't know if the syntax is correct or if it will look > well, but at least the information should be there.) Great! I'll fix a few things to make it look good. > I have also made some additions/changes to the compile command used. > The user can now specify the argument variables > DFLAGS, DLINKFLAGS, DDEBUG, DOPTIMIZE and DVERSION. I think you need to give a bit more explanation about using $DVERSION. > Except for the DLINKFLAGS, all of the arguments can in theory be put > into the DFLAGS variable, but the rationale is to make it easier for the > user to see what goes where and that the D language has the possibility > to specify lots of debug and version flags that decide which parts of the > code to compile (a preprocessor replacement). > > These changes can be found in d.diff and dmd.diff This makes me wonder how we should use the optional arguments for a compiler other than the C or C++ compiler. For C we use $CFLAGS, $DEFINE, $INCLUDE, $DEBUG and $OPTIMIZE. The idea is that all C compilers use these and convert them from the standard syntax (what is used on Unix) to whatever the compiler accepts. Since the D language appears to use similar arguments, should we use the same variables, or with a "D" prepended, like what Lars is using now? I think we should at least be consistent, thus either use the C flags for D as well, or only use D specific flags. That means $INCLUDE should not be used for D as it is now. On the other hand, $DEBUG and $OPTIMIZE are not arguments, but generic Aap settings. $DEBUG can be set to "yes". $OPTIMIZE is a number from zero to nine. For C the cflags_normal() function is used to turn them into arguments for the C compiler. Let me do a proposal: - For each language we have a set of variables similar to $CFLAGS, $DEFINE and $INCLUDE, but specific for that langauge. This is logical, since using the values given to the C compiler would probably not work for another language. For D we have $DFLAGS, $DDEFINE and $DINCLUDE. And as an extra $DVERSION, which is apparently specific for D. - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE variables. These need to be converted to arguments that the specific compiler accepts. For the D module and tool this shell command would be used: $DMD $?DFLAGS $?DVERSION $?DDEFINE $?DINCLUDE -of$target -c $source $DEBUG and $OPTIMIZE could be used as well, if you know what dmd areguments are used for this. -- Time is money. Especially if you make clocks. /// 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: Lars I. I. <lar...@ig...> - 2003-10-02 08:09:57
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > I think you need to give a bit more explanation about using $DVERSION. I think I need to explain other things more, too. Look further down. > > > Except for the DLINKFLAGS, all of the arguments can in theory be put > > into the DFLAGS variable, but the rationale is to make it easier for the > > user to see what goes where and that the D language has the possibility > > to specify lots of debug and version flags that decide which parts of the > > code to compile (a preprocessor replacement). > > > > These changes can be found in d.diff and dmd.diff > > This makes me wonder how we should use the optional arguments for a > compiler other than the C or C++ compiler. > > For C we use $CFLAGS, $DEFINE, $INCLUDE, $DEBUG and $OPTIMIZE. The idea > is that all C compilers use these and convert them from the standard > syntax (what is used on Unix) to whatever the compiler accepts. > > Since the D language appears to use similar arguments, should we use the > same variables, or with a "D" prepended, like what Lars is using now? > > I think we should at least be consistent, thus either use the C flags > for D as well, or only use D specific flags. That means $INCLUDE should > not be used for D as it is now. Good point. I just kept using it, since dmd use the same syntax for include paths. > > On the other hand, $DEBUG and $OPTIMIZE are not arguments, but generic > Aap settings. $DEBUG can be set to "yes". $OPTIMIZE is a number from > zero to nine. For C the cflags_normal() function is used to turn them > into arguments for the C compiler. > > Let me do a proposal: > > - For each language we have a set of variables similar to $CFLAGS, > $DEFINE and $INCLUDE, but specific for that langauge. This is > logical, since using the values given to the C compiler would probably > not work for another language. > For D we have $DFLAGS, $DDEFINE and $DINCLUDE. And as an extra > $DVERSION, which is apparently specific for D. Ok; DFLAGS is ok, DDEFINE not very useful, except if people start using external preprocessors for D (which the language designer wants to avoid) DINCLUDE is for including stuff, but they are called imports in D (like Java). Should DIMPORT be the name, perhaps? DVERSION would be for the compiler arguments -version=level and -version=ident. Several idents and a level can be used to compile in or out parts of the source. It usually looks like this: version (bar) { .... .... } version (foo) { .... .... } DDEBUG was proposed by me because it in addition to setting the flags -g [symbolic debug info] and -gt [trace profiling hooks], it is also possible to compile in (and out) debug code in much the same way as with -version. The main difference as I see it, is that debug code don't HAVE to be qualified by an identifier or level. Also, it will always be compiled out when the release flag is used (probably as a DFLAG). Compiling/excluding unittests is also a part of this, as is contracts. OPTIMIZE might make sense as it is now. The current version of the compiler takes only one optimize flag, -O, but it would probably be ignorant not to expect more. > > - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE > variables. These need to be converted to arguments that the specific > compiler accepts. (As an aside on OPTIMIZE; the Open Watcom compiler have very many optimizeflags that I don't think fit into the 0-9 scheme. > > $DEBUG and $OPTIMIZE could be used as well, if you know what dmd > areguments are used for this. As mentioned above; this might work well for OPTIMIZE. For DEBUG, I think there are too many options. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-02 11:08:46
|
Lars Ivar Igesund wrote: > > I think you need to give a bit more explanation about using $DVERSION. > > I think I need to explain other things more, too. Look further down. Please correct and extend the docs in ref-modules when needed. > > On the other hand, $DEBUG and $OPTIMIZE are not arguments, but generic > > Aap settings. $DEBUG can be set to "yes". $OPTIMIZE is a number from > > zero to nine. For C the cflags_normal() function is used to turn them > > into arguments for the C compiler. > > > > Let me do a proposal: > > > > - For each language we have a set of variables similar to $CFLAGS, > > $DEFINE and $INCLUDE, but specific for that langauge. This is > > logical, since using the values given to the C compiler would probably > > not work for another language. > > For D we have $DFLAGS, $DDEFINE and $DINCLUDE. And as an extra > > $DVERSION, which is apparently specific for D. > > Ok; > DFLAGS is ok, > DDEFINE not very useful, except if people start using external > preprocessors for D (which the language designer wants to avoid) That means it's better to leave $DDEFINE out, right? > DINCLUDE is for including stuff, but they are called imports in D > (like Java). Should DIMPORT be the name, perhaps? Avoiding confusion between $INCLUDE and $DINCLUDE is good. Using $DIMPORT sounds logical to me. > DVERSION would be for the compiler arguments -version=level and > -version=ident. Several idents and a level can be used to compile > in or out parts of the source. It usually looks like this: OK, thus it's a language-related argument that has a specific syntax. It's good to keep these separate from $DFLAGS, so that they can be translated if there is a D compiler that uses /v:ident instead of -version=indent, for example. > DDEBUG was proposed by me because it in addition to setting the flags > -g [symbolic debug info] and -gt [trace profiling hooks], it > is also possible to compile in (and out) debug code in much > the same way as with -version. > The main difference as I see it, is that debug code don't HAVE > to be qualified by an identifier or level. Also, it will > always be compiled out when the release flag is used (probably > as a DFLAG). Compiling/excluding unittests is also a part of > this, as is contracts. It only makes sense to add arguments to a specific variable if we can do something with it. The use of $DEBUG is that the tool can check the value and then add the appropriate argument to the compiler. This only works for generic settings, in this case debugging on/off. If the compiler has specific arguments that other compilers are unlikely to have, these can be added to $DFLAGS. It's then up to the recipe writer to use the right arguments, since Aap can't offer him a generic way of doing it. This means the recipe isn't portable to another compiler. This would require a configure check. The same applies to optimizing flags. > OPTIMIZE might make sense as it is now. The current version of the > compiler takes only one optimize flag, -O, but it would probably > be ignorant not to expect more. > > > - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE > > variables. These need to be converted to arguments that the specific > > compiler accepts. You could probably use something like: @if _no.OPTIMIZE and int(_no.OPTIMIZE) > 0: oarg = -O @else: oarg = :sys $DMD ... $oarg ... -- hundred-and-one symptoms of being an internet addict: 77. The phone company asks you to test drive their new PBX system /// 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: Lars I. I. <lar...@ig...> - 2003-10-02 13:30:45
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > Please correct and extend the docs in ref-modules when needed. Yes, I will. > That means it's better to leave $DDEFINE out, right? IMO, yes. > > > DINCLUDE is for including stuff, but they are called imports in D > > (like Java). Should DIMPORT be the name, perhaps? > > Avoiding confusion between $INCLUDE and $DINCLUDE is good. Using > $DIMPORT sounds logical to me. Great minds, etc :) > > > DVERSION would be for the compiler arguments -version=level and > > -version=ident. Several idents and a level can be used to compile > > in or out parts of the source. It usually looks like this: > > OK, thus it's a language-related argument that has a specific syntax. > It's good to keep these separate from $DFLAGS, so that they can be > translated if there is a D compiler that uses /v:ident instead of > -version=indent, for example. Yep. > > > DDEBUG was proposed by me because it in addition to setting the flags > > -g [symbolic debug info] and -gt [trace profiling hooks], it > > is also possible to compile in (and out) debug code in much > > the same way as with -version. > > The main difference as I see it, is that debug code don't HAVE > > to be qualified by an identifier or level. Also, it will > > always be compiled out when the release flag is used (probably > > as a DFLAG). Compiling/excluding unittests is also a part of > > this, as is contracts. > > It only makes sense to add arguments to a specific variable if we can do > something with it. The use of $DEBUG is that the tool can check the > value and then add the appropriate argument to the compiler. This only > works for generic settings, in this case debugging on/off. If the > compiler has specific arguments that other compilers are unlikely to > have, these can be added to $DFLAGS. It's then up to the recipe writer > to use the right arguments, since Aap can't offer him a generic way of > doing it. This means the recipe isn't portable to another compiler. > This would require a configure check. I understand you, but I don't think I explained myself good enough. Debug constructs are a part of the language in the same way as version constructs are. Thus a $DDEBUG variable should be present IMHO. I also agree that the recipe writer must know if he use other compiler specific flags. :usetool and :conf should be a good help then. > > The same applies to optimizing flags. > > > OPTIMIZE might make sense as it is now. The current version of the > > compiler takes only one optimize flag, -O, but it would probably > > be ignorant not to expect more. > > > > > - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE > > > variables. These need to be converted to arguments that the specific > > > compiler accepts. > > You could probably use something like: > > @if _no.OPTIMIZE and int(_no.OPTIMIZE) > 0: > oarg = -O > @else: > oarg = > > :sys $DMD ... $oarg ... Just what I was thinking. I guess this must be present in the dmd.py too. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-02 19:26:59
|
Lars Ivar Igesund wrote: > I understand you, but I don't think I explained myself good enough. > Debug constructs are a part of the language in the same way as version > constructs are. Thus a $DDEBUG variable should be present IMHO. OK, then we should add $DDEBUG and explain what values Aap understands. Then it will work for kinds of D compilers. That is, the tool will convert $DDEBUG to what the compiler understands. > > The same applies to optimizing flags. > > > > > OPTIMIZE might make sense as it is now. The current version of the > > > compiler takes only one optimize flag, -O, but it would probably > > > be ignorant not to expect more. > > > > > > > - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE > > > > variables. These need to be converted to arguments that the > > > > specific compiler accepts. > > > > You could probably use something like: > > > > @if _no.OPTIMIZE and int(_no.OPTIMIZE) > 0: > > oarg = -O > > @else: > > oarg = > > > > :sys $DMD ... $oarg ... > > Just what I was thinking. I guess this must be present in the dmd.py too. Yep. I have collected the remarks and modified the tool and module. Please check version 1.037! -- If bankers can count, how come they have eight windows and only four tellers? /// 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: Bram M. <Br...@mo...> - 2003-10-02 20:57:39
|
I wrote: > I have collected the remarks and modified the tool and module. Please > check version 1.037! Currently there is something wrong with the sourceforge site, I'm unable to upload anything. That includes CVS and the web site :-(. It appears to be a problem with ssh. -- hundred-and-one symptoms of being an internet addict: 82. AT&T names you Customer of the Month for the third consecutive time. /// 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: Lars I. I. <lar...@ig...> - 2003-10-03 08:15:05
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > I wrote: > > > I have collected the remarks and modified the tool and module. Please > > check version 1.037! > > Currently there is something wrong with the sourceforge site, I'm unable > to upload anything. That includes CVS and the web site :-(. It appears > to be a problem with ssh. I don't know if it's related, but the changes I get out of (anonymous) CVS now don't match our latest agreements. Is anon CVS still lagging very much behind? Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-03 10:03:53
|
Lars Ivar Igesund wrote: > > I wrote: > > > > > I have collected the remarks and modified the tool and module. Please > > > check version 1.037! > > > > Currently there is something wrong with the sourceforge site, I'm unable > > to upload anything. That includes CVS and the web site :-(. It appears > > to be a problem with ssh. > > I don't know if it's related, but the changes I get out of (anonymous) CVS > now don't match our latest agreements. Is anon CVS still lagging very > much behind? Sourceforge is working again now, I've just checked in version 1.037. You can find out if anonymous CVS still has an older version. -- hundred-and-one symptoms of being an internet addict: 85. Choice between paying Compuserve bill and paying for kids education is a no brainer -- although a bit painful for your kids. /// 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: Lars I. I. <lar...@ig...> - 2003-10-05 11:19:46
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > > Sourceforge is working again now, I've just checked in version 1.037. > You can find out if anonymous CVS still has an older version. Well, the transition didn't happen instantanously, but it's updated now. :) I made a change that did the same with the $DEBUG variable as with the $OPTIMIZE variable. (See diffs d.diff and dmd.diff). I also documented this in the ref-modules (togethere with $OPTIMIZE). I also added some anchor id's plus a ref-tools.sgml page. (I'm still very unsure about the doc syntax. How do I build the html-files when I've changed a sgml-file?) Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-06 20:12:43
|
Lars Ivar Igesund wrote: > I made a change that did the same with the $DEBUG variable as with the > $OPTIMIZE variable. (See diffs d.diff and dmd.diff). Good. I'll include this. Perhaps the tool should mention $DDEBUG like it's explained in the d module? > I also documented this in the ref-modules (togethere with $OPTIMIZE). > I also added some anchor id's plus a ref-tools.sgml page. (I'm still > very unsure about the doc syntax. How do I build the html-files when > I've changed a sgml-file?) Please read doc/README.txt. That should explain it all... Hopefully! It's amazing you wrote these doc file updatess without a syntax error! I'll include your patches. I won't have time to release the updated version today, hopefully tomorrow. -- I AM THANKFUL... ...for a lawn that needs mowing, windows that need cleaning and gutters that need fixing because it means I have a home. /// 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: Lars I. I. <lar...@ig...> - 2003-10-07 19:39:51
Attachments:
ref-tools.sgml
|
----- Original Message ----- From: "Bram Moolenaar" <Br...@mo...> > Perhaps the tool should mention $DDEBUG like it's explained in the d > module? The new version (I added only a small line) is attached. > It's amazing you wrote these doc file updatess without a syntax error! Maybe I can put it on my CV :) I might help me get a job. Lars Ivar Igesund |
From: Bram M. <Br...@mo...> - 2003-10-08 11:31:11
|
Lars Ivar Igesund wrote: > > Perhaps the tool should mention $DDEBUG like it's explained in the d > > module? > > The new version (I added only a small line) is attached. Thanks, I'll include it. I have just checked in version 1.039. Please try out this version. If the D, qt and libtool modules look OK now then I'll make a .zip file release. -- hundred-and-one symptoms of being an internet addict: 103. When you find yourself in the "Computer" section of Barnes & Noble enjoying yourself. /// 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 /// |