Menu
▾
▴
opencxx-users
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(16) |
Nov
(14) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(14) |
Feb
(57) |
Mar
(72) |
Apr
(37) |
May
(21) |
Jun
(12) |
Jul
(16) |
Aug
(33) |
Sep
(24) |
Oct
|
Nov
(10) |
Dec
(8) |
| 2004 |
Jan
(6) |
Feb
(14) |
Mar
(47) |
Apr
(41) |
May
(16) |
Jun
(31) |
Jul
(78) |
Aug
(62) |
Sep
(99) |
Oct
(43) |
Nov
(35) |
Dec
(9) |
| 2005 |
Jan
(19) |
Feb
(22) |
Mar
(7) |
Apr
|
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(9) |
Sep
(15) |
Oct
(23) |
Nov
(2) |
Dec
(20) |
| 2006 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
(8) |
Jul
(15) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stefan S. <sse...@ar...> - 2004-11-01 14:53:50
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: November 1, 2004 08:44 > I guess that you prefer the approach that is described by the > papers on the page "http://keystone.sourceforge.net/research.shtml". > Would you like to reuse the software that was developed by > the other project? You asked this question already in another thread. My answer is still 'no'. For reasons see earlier discussions. Regards, Stefan |
|
From: Iwan B. <iwa...@bl...> - 2004-11-01 09:47:56
|
Hello, Is it possible to transform C/C++ source code in a way that the layout of the original source code is preserved? Or is it possble to parse and anylize code while the layout information is available is the AST. Iwan |
|
From: Markus E. <Mar...@we...> - 2004-10-29 21:24:01
|
> > Is the meta-compilation approach worth a try, too? > What do you mean? Please look at the papers about a "Flexible Object Generator". http://www.computing.surrey.ac.uk/research/dsrg/fog/ http://citeseer.ist.psu.edu/251920.html Regards, Markus |
|
From: Markus E. <Mar...@we...> - 2004-10-29 21:20:57
|
> well, that looks like sloppy use of the language, which is quite unfortunate. > > Please try to conceive of an example of code that maps to a graph > on the syntax level. Until I see that I'd rather insist on the > conventional use of the above acronyms, may be putting a glossary into > the docs to make sure people understand what we are referring to. Can another paper show more use cases? An Object-Oriented Approach to C++ Compiler Technology Cristian Sminchisescu, Alexandru Telea http://citeseer.ist.psu.edu/55096.html Regards, Markus |
|
From: Markus E. <Mar...@we...> - 2004-10-29 19:46:12
|
> > Is the meta-compilation approach worth a try, too? > What do you mean? Please look the papers about the "Flexible Object Generator". http://www.computing.surrey.ac.uk/research/dsrg/fog/ http://citeseer.ist.psu.edu/251920.html Regards, Markus |
|
From: Vladimir P. <gh...@cs...> - 2004-10-29 08:50:03
|
On Friday 29 October 2004 00:28, you wrote: > > Given that, it's not all clear that Entities are constructed after > > parsing. Given an appropriate design of "Processor", the steps can be > > interleaved. > > Which thoughts do you have with "interleaving"? Specifically, that high-level semantic objects are created as soon as they are parsed. > Have you looked at the Keystone approach for the separation of concerns? It looks like it does create scopes and NameDeclaration objects directly during parsing, not in a separate pass. It's exactly what I propose. > Is the meta-compilation approach worth a try, too? What do you mean? - Volodya |
|
From: Dave A. <da...@st...> - 2004-10-28 21:31:33
|
On Thu, 28 Oct 2004 13:04:58 -0400 Stefan Seefeld <sse...@ar...> wrote: > Are you suggesting that my interpretation of 'AST' as I > described it is different from the conventional use ? Or > that using both terms (AST as well as ASG) together is > a bad idea ? > > Regards, > Stefan > Mostly the former, but take your pick ;-) [Caveat: I could be wrong, but that's my understanding] -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
|
From: Stefan S. <sse...@ar...> - 2004-10-28 17:13:32
|
David Abrahams wrote: >Vladimir Prus <gh...@cs...> writes: > >>On Tuesday 26 October 2004 08:16, Stefan Seefeld wrote: >> >>>The Abstract Semantic Graph (*ASG*) is a structure that is built from >>>the AST (or PTree), but where identifiers are cross-referenced to their >>>respective declarations (thus it's a graph, not a tree). >> >>I think that "Abstract" and "Semantic" words are all very confusing. >>Basically, you description of ASG says it's just a set of interlinked C++ >>objects. Semantic could mean anything, including operational semantic (how >>i+1 is prorcessed and so on). I'd suggest to name this module just "Objects", >>or "Entities", to avoid further confusion. > > >Also, the term AST has a well-known meaning which, I'm pretty sure, >does not constrain it to denote pure trees, nor pure syntax. >Choosing a different meaning in the name of "clarity" might be a bad >idea. Are you suggesting that my interpretation of 'AST' as I described it is different from the conventional use ? Or that using both terms (AST as well as ASG) together is a bad idea ? Regards, Stefan |
|
From: David A. <da...@bo...> - 2004-10-28 15:32:26
|
Vladimir Prus <gh...@cs...> writes: > On Tuesday 26 October 2004 08:16, Stefan Seefeld wrote: > >> The Abstract Semantic Graph (*ASG*) is a structure that is built from >> the AST (or PTree), but where identifiers are cross-referenced to their >> respective declarations (thus it's a graph, not a tree). > > I think that "Abstract" and "Semantic" words are all very confusing. > Basically, you description of ASG says it's just a set of interlinked C++ > objects. Semantic could mean anything, including operational semantic (how > i+1 is prorcessed and so on). I'd suggest to name this module just "Objects", > or "Entities", to avoid further confusion. Also, the term AST has a well-known meaning which, I'm pretty sure, does not constrain it to denote pure trees, nor pure syntax. Choosing a different meaning in the name of "clarity" might be a bad idea. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
|
From: Vladimir P. <gh...@cs...> - 2004-10-28 11:16:23
|
On Tuesday 26 October 2004 08:16, Stefan Seefeld wrote: > The Abstract Semantic Graph (*ASG*) is a structure that is built from > the AST (or PTree), but where identifiers are cross-referenced to their > respective declarations (thus it's a graph, not a tree). I think that "Abstract" and "Semantic" words are all very confusing. Basically, you description of ASG says it's just a set of interlinked C++ objects. Semantic could mean anything, including operational semantic (how i+1 is prorcessed and so on). I'd suggest to name this module just "Objects", or "Entities", to avoid further confusion. > Also, at this > level of abstraction there is very little connection to the syntax, so > the type hierarchy can be simplified (compared to the ugly mix of type, > identifier, and other tokens that C++ declarations usually are made of). > Construction of the ASG is done by traversing the AST while looking up > symbols in the SymbolTable. It is done after the parsing has finished. Traversing AST or PTree? The difference between the too is confusing as well. If PTree is just a grouping of input tokens into blocks (class definitions, functions), and "Entities" is high-level classes and functions (no trace of syntax), then there's very little place left for any other layer. I'm still not sure that this reprsentation can be constructed after parsing. We've talked with you that during parsing you need to instantiate templates, and it's not clear if PTree representation is rich enough to handle such functionality. In fact, now that you've sketched the diagram and explained they layers, I think we need to agree what PTree does. For example: PTree -- just grouping of tokens, as little semantic information as possible. Entities -- reach semantic information, including logic for instantiating templates, template argument deduction and so on. Given that, it's not all clear that Entiries are constructed after parsing. Given an appropriate design of "Processor", the steps can be interleaved. - Volodya |
|
From: Stefan S. <se...@sy...> - 2004-10-28 00:22:31
|
Markus Elfring wrote: >>Can you show where the syntax tree becomes a graph ? It never occured to >>me that syntax would have an intrinsic graph structure (as long as you >>don't start to connect symbol declarations with their actual use, but >>that's exactly what the ASG is about). > > > I can not show it. The specific term is rarely used by Keystone. > It seems that it is related to other documents as a background. > http://citeseer.ist.psu.edu/cis?q=%22abstract+syntax+graph%22 well, that looks like sloppy use of the language, which is quite unfortunate. Please try to conceive of an example of code that maps to a graph on the syntax level. Until I see that I'd rather insist on the conventional use of the above acronyms, may be putting a glossary into the docs to make sure people understand what we are referring to. Regards, Stefan |
|
From: Stefan S. <se...@sy...> - 2004-10-27 12:01:42
|
Markus Elfring wrote: >>Note that Synopsis already contains an ASG, though confusingly calls it 'AST'. > > > Please consider that the syntax tree can also become a syntax graph like in the Keystone approach. > > S = syntax or semantic > T = tree, G = graph > > Is more "confusion" needed? What exactly is your point ? The (mis-)use of acronyms ? Can you show where the syntax tree becomes a graph ? It never occured to me that syntax would have an intrinsic graph structure (as long as you don't start to connect symbol declarations with their actual use, but that's exactly what the ASG is about). I'm not (yet) that familiar with keystone, so if you could post a concrete example of a code snippet that has graph structure (in its keystone representation) that would help. Thanks, Stefan |
|
From: Markus E. <Mar...@we...> - 2004-10-27 07:49:30
|
> I'm putting together a list of relevant articles and > other documents that are of potential use in this context. > I'v put the page tentatively at http://synopsis.fresco.org/reading.html. Would you also like to add links to related projects on this page? - OpenC++ - Keystone - Doxygen Does it make sense to add a similar page at "http://opencxx.sourceforge.net/" or "http://www.csg.is.titech.ac.jp/~chiba/openc++.html"? Regards, Markus |
|
From: Stefan S. <se...@sy...> - 2004-10-26 04:19:35
|
hi there, as I'm reading through the literature for inspiration for the actual design tasks (http://synopsis.fresco.org/issues/task), I'm putting together a list of relevant articles and other documents that are of potential use in this context. I'v put the page tentatively at http://synopsis.fresco.org/reading.html. One thing that becomes more and more clear is the workflow from low level syntactic data to high level semantic data. During the processing there a number of 'intermediate representations' of the code may be generated. I'v put a temporary graphic of the module view as I currently see it at http://synopsis.fresco.org/cxx-parser.png. Here are some remarks: The Parse Tree (*PTree*) is what the C++ parser currently generates. It is based on an external buffer of characters, and the API provides the means to replace one subgraph by a (or insert/add an entirely new) generated tree. The Abstract Syntax Tree (*AST*) is an optional refinement that reduces the API by giving direct access to the typed subnodes (an 'if' statement contains a 'condition' expression and a statement, etc.) and hides the purely syntactic tokens such as ';', '{', '}', etc. At this point it is not clear whether the AST deserves a module (namespace) of its own, or whether the API can simply be added to the existing PTree classes. The *SymbolTable* is what we are currently working on. It stores type- and other information about declared identifiers. Some of this information is required to disambiguate certain C++ expressions, and so the construction of the datastructure has to be done during the parsing. The Abstract Semantic Graph (*ASG*) is a structure that is built from the AST (or PTree), but where identifiers are cross-referenced to their respective declarations (thus it's a graph, not a tree). Also, at this level of abstraction there is very little connection to the syntax, so the type hierarchy can be simplified (compared to the ugly mix of type, identifier, and other tokens that C++ declarations usually are made of). Construction of the ASG is done by traversing the AST while looking up symbols in the SymbolTable. It is done after the parsing has finished. Note that Synopsis already contains an ASG, though confusingly calls it 'AST'. Various inspection tools have different requirements for the APIs they operate on. A code manipulating / generating tool will likely operate on the PTree / AST level, while document generation and code navigation is based on the ASG. I'm thus considering to rename the Synopsis.AST module to 'Synopsis.ASG'. 'Synopsis.AST' will be a python wrapper around the C++ PTree module, or AST, if it will be defined. The current synopsis processing pipeline will be an 'ASG processor pipeline', with an equivalent facility being defined for ASTs (for code-to-code translation and other metaprogramming tasks). Comments, suggestions, and criticism are, as allways, highly appreciated ! Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-25 20:55:08
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 25, 2004 16:47 > > It may help if you would summarize the approaches you want to > > get votes on. > > 1. Edward D. Willink: Meta-Compilation for C++ > transformation and filtering of a superset to the target language > > 2. James F. Power, Tanton H. Gibbs and Brian A. Malloy: Keystone > token decoration > > Is this summary too short? That's not a summary. That are the titles of the documents. > Would you like to look at the referenced documents? yeah, but I don't need your help for that :-) I believe presenting the outline of the ideas would be more stimulating than just pointing at papers other people have written. I have read the papers you mention. I don't think voting is an appropriate approach to agree on a design. What we need is IMO a technical discussion on the merrits of the various approaches. That's why I'm asking for a short abstract (yours, not the ones in the papers). Regards, Stefan |
|
From: SF M. E. <el...@us...> - 2004-10-25 20:47:16
|
> It may help if you would summarize the approaches you want to > get votes on. 1. Edward D. Willink: Meta-Compilation for C++ transformation and filtering of a superset to the target language 2. James F. Power, Tanton H. Gibbs and Brian A. Malloy: Keystone token decoration Is this summary too short? Would you like to look at the referenced documents? Regards, Markus |
|
From: Stefan S. <sse...@ar...> - 2004-10-25 12:46:54
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 22, 2004 17:53 > Would any developer who is subscribed to the OpenC++ mailing > list like to vote for a specific approach? It may help if you would summarize the approaches you want to get votes on. Regards, Stefan |
|
From: SF M. E. <el...@us...> - 2004-10-24 13:17:04
|
> > Merging code enhancements means creating derivative work of code covered
> > by LGPL. Such work can only be distributed under LGPL (or GPL). This
>
> sorry, but that's entirely false, both, for GPL as well as LGPL.
>
> > means that you have to fulfill certain obligations if you want to
> > distribute a program that uses the library (see LGPL item 6)
>
> this isn't the same as what you said above. Nothing forces you to change
> your license just because you link to LGPL code. It is true however that
> for the part of the code that is covered by LGPL you have to follow some
> rules (such as the ones you refer to).
>
> Also note that we are *not* talking about GPL here.
What is your opinion to the answer for the question "How is that different from the GNU {Lesser,Library} GPL?" on the page "http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html"?
Is the running discussion "(L)GPL and C++ templates issue" (http://groups.google.de/groups?group=comp.lang.c%2B%2B.moderated&threadm=4174046c%241_2%40news.bluewin.ch) of any help for the further OpenC++ development?
Regards,
Markus
|
|
From: Stefan S. <sse...@ar...> - 2004-10-22 20:05:13
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 22, 2004 15:31 > > As in the Clouseau API identifiers (strings) are helt by value > > and not by reference, you can't simply modify the parse tree > > *in place*. What Grzegorz and I discussed a while ago was a way > > to access (and that includes modify) the underlaying structure. > > Which identifiers do you mean? Is it needed in that design > that they behave as value objects? Why not in OpenC++? > Are you concerned about the consequences on memory consumption? no, I'm interested in in-place code manipulation, i.e. modifications to the AST that propagate automagically down to the underlaying parse tree / source code buffer. > > > Do you think about a concrete class hierarchy for more > introspection? > > > > I don't understand the question. As I said earlier, both the parse > > tree as well as the symbol table (and assorted analyzers) provide > > the means to introspect the code. the AST API would simply be > > a convenient high level view on these two. There isn't any more > > information that is not already available through the PTree and > > the SymbolTable modules. > > I assume that your understanding of a AST/ASG API might > result in a variant of a Clouseau API. well, all AST APIs will have many similarities as they all model the same domain. > I think that you will need a couple of related classes for > your implementation. Have any plans become concrete enough so > that more details can be disussed? not yet, no. My immediate goal is to finish the SymbolTable work at least down to a degree that allows the parser to completely disambiguate its input. > Is the topic "token decoration" also on your approach? Conceptually yes, as the work to be done is the same: Get a token from the lexer, and if it is an 'Identifier' find out whether it is a known symbol. If it is, choose the production rule according to the symbol type. That's what all disambiguation is about, no matter whether you describe it as 'token decoration' or in different terms. I haven't looked closely into the keystone parser but since it's written more formally in terms of bison, I think a formal on-the-fly decoration of the incoming token is a good approach. In our case the parser is hand-written so there is no need to do it exactly the same way. > > > Would you like to apply the design patterns "adaptor" or > > > "facade" like it is done in Keystone? [...] ok, yes, the goal being to decouple the submodules as well as possible. Using a single entry point for the parser to access the SymbolTable module looks like a good idea. Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-21 19:03:22
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 21, 2004 14:27 > What do you have got in mind with this "superstructure"? > How is it different from a "Inspector Clouseau API"? As in the Clouseau API identifiers (strings) are helt by value and not by reference, you can't simply modify the parse tree *in place*. What Grzegorz and I discussed a while ago was a way to access (and that includes modify) the underlaying structure. > Do you think about a concrete class hierarchy for more introspection? I don't understand the question. As I said earlier, both the parse tree as well as the symbol table (and assorted analyzers) provide the means to introspect the code. the AST API would simply be a convenient high level view on these two. There isn't any more information that is not already available through the PTree and the SymbolTable modules. > Would you like to apply the design patterns "adaptor" or > "facade" like it is done in Keystone? can you should an example of what you have in mind ? Regards, Stefan |
|
From: SF M. E. <el...@us...> - 2004-10-21 18:29:05
|
> I think the key requirement should be to keep the underlaying data > representation, i.e. instead of copying data out of the buffer / parse > tree the AST should be a true superstructure. > If it was not, you couldn't manually modify the AST and regenerate source > code from it as is possible with the PTree API. What do you have got in mind with this "superstructure"? How is it different from a "Inspector Clouseau API"? Do you think about a concrete class hierarchy for more introspection? Would you like to apply the design patterns "adaptor" or "facade" like it is done in Keystone? I suggest to consider also the term "abstract syntax/semantic graph" (ASG) besides AST. Regards, Markus |
|
From: SF M. E. <el...@us...> - 2004-10-21 18:26:58
|
> I think the key requirement should be to keep the underlaying data > representation, i.e. instead of copying data out of the buffer / parse > tree the AST should be a true superstructure. > If it was not, you couldn't manually modify the AST and regenerate source > code from it as is possible with the PTree API. What do you have got in mind with this "superstructure"? How is it different from a "Inspector Clouseau API"? Do you think about a concrete class hierarchy for more introspection? Would you like to apply the design patterns "adaptor" or "facade" like it is done in Keystone? I suggest to consider also the term "abstract syntax/semantic graph" (ASG) besides AST. Regards, Markus |
|
From: Stefan S. <sse...@ar...> - 2004-10-20 21:09:17
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 20, 2004 16:50 > I hope that the accessibility can be enhanced by an interface > that will be similar to the Keystone-"Inspector Clouseau API". > I am not sure when it would become too "heavy". I think the key requirement should be to keep the underlaying data representation, i.e. instead of copying data out of the buffer / parse tree the AST should be a true superstructure. If it was not, you couldn't manually modify the AST and regenerate source code from it as is possible with the PTree API. Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-19 13:03:44
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 19, 2004 07:47 > > Right now I'm aiming at a modular structure with three or > four (logical) > > modules: PTree, SymbolTable, AST, and Processor. That's roughly in > > alignment with the above papers, and a natural (smooth) evolution > > for the OpenC++ design itself. > > How much can be reused from the Keystone-"Clouseau API" for > the high level AST interface that was discussed before? probably nothing, for a variety of reasons: * as discussed before, OpenCxx's approach is to attach a structure (the parse tree) to a buffer, instead of constructing an independent structure that uses its own storage. It would be much more sensible to push that further and let the AST be a superstructure on top of the parse tree instead of using existing AST code, i.e. the AST should be dependent on the PTree module. * Keystone is, as you already mentioned, licensed under GPL, and so not suitable for middleware / framework development. Anyways, as Grzegorz and I discussed some months ago, an AST module can and should really be something very lightweight. It doesn't add new functionality, it only makes existing information more accessible and more convenient to use. The real information providers are the PTree and the SymbolTable modules, for syntactic and semantic analysis respectively. Regards, Stefan |
|
From: Grzegorz J. <ja...@ac...> - 2004-10-18 13:25:07
|
Marc Waeckerlin wrote: > Now I have a C++ compiler executable named "trace", which > changes all classes by adding function trace to all member > functions. > > If I compile with > trace -I /path/to/fntrace -d-include -dfntrace.hxx \ > -- -o x x.cpp > instead of > g++ -o x x.cpp > > Then my classes in x.cpp print a very verbose function > trace. > > Now I have created a huge project with GNU Autotools, so to > build it, simply call: > ./configure && make > > Question: > > Can I exchange the GNU g++ by my own "trace" without > changing a single line in my project? > > Approach: > > The first approach is: > CXX="trace -I <path> -d-include -dfntrace.hxx --" \ > ./configure && make > > But unfortunately configure fails because link options are > not passed to the linker, i.e. The following does not work: > trace <as-above> -- -o x x.cpp -liberty > > But I get the error message: > [MetaclassRegistration...] > EXECUTING g++ g++ -I <path> -include fntrace.hxx \ > -liberty -D__opencxx -E -o conftest.occ \ > -x c++ conftest.cc > g++: -liberty: linker input file unused because \ > linking not done > EXECUTING g++ g++ -o conftest -g -O2 conftest.ii > > -> Link errors, because the second, not the first call, > must be with -liberty, but the second call is missing > the link option. Why? > > Is this a bug or missing feature in OpenC++? I think so. This is missing feature of Autoconf that does not recognize compilers generated by OpenC++ :-) Seriously, AFAIK OpenC++ was not designed with a goal of being a drop-in replacement for any particular compiler. However, one of goals of OpenC++Core project is to make OpenC++ more modular, so that you can seamlesly reuse parts you need (lexer, parser, analyzer, translator, metaobject protocol, driver), but replace the one that does not suit you (command-line options interpretter). You may also want to have a look at occ2 script, which duplicates funcionality of driver and command-line line options interpretter in Python. It should be easier to modify this script than C++ driver to obtain drop-in replacement. Yet another solution is to ./configure with genuine compiler, but later use "make CXX='trace ...'". > Other question: > How do I split my homebrew enhanced compiler "trace" into > the three common steps: Preprocessing, compiling, linking? > I suppose, I only need my own compiler for preprocessing, > i.e. to generate x.ii, then for compiling and linking, I > can use the normal g++? Right. Use '-E' command-line option to generated compiler. 'occ2' works like this --- the generated compiler is used only for translation, all other tasks are run from occ2 script using genuine preproc, genuing compiler and genuine linker. BR Grzegorz > > Thank you > Regards > Marc > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users |
7 messages has been excluded from this view by a project administrator.
