opencxx-users

RE: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[Stefan S. <sse...@ar...>]

> From: Grzegorz Jakacki [mailto:ja...@ac...]
> Sent: October 18, 2004 09:07

> > The topic doesn't appear to be as dead as you make it sound
> > (as this very thread proves). May I remind you that you were the one
> > bringing the topic up, so all people are asking now is why 
> you insist
> > on not wanting to use LGPL.
> 
> "All people" means who? So far two persons were asking (you and Eric 
> Hopper).

sorry, a grammatical ambiguity. I meant "...all that people are asking..."
:-)

> > By the way, you asked for comments on potential licenses for future
> > OpenCxx versions about a month ago. Was there any follow-up ?
> 
> Four persons responded, two of them in private e-mails (Hilde 
> opted for 
> Boost license, RodZilla would accept either of LGPL, MIT and Boost).

ok, thanks.

Regards,
		Stefan

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[Grzegorz J. <ja...@ac...>]

Hi,

Stefan Seefeld wrote:
>>From: Grzegorz Jakacki [mailto:ja...@ac...]
>>Sent: October 12, 2004 07:12
> 
> 
>>Pls. google for the answer, this subject has been beaten to 
>>death many 
>>times on different fora and seems to be religious issue, no point in 
>>bringing it here.
> 
> 
> The topic doesn't appear to be as dead as you make it sound
> (as this very thread proves). May I remind you that you were the one
> bringing the topic up, so all people are asking now is why you insist
> on not wanting to use LGPL.

"All people" means who? So far two persons were asking (you and Eric 
Hopper).

Apart of that you yourself were insisting that this topic is of not 
particular interest to others:

[previous private e-mail:]
 > I'm replying only to you since I don't think at this point
 > there is much interest for others (in particular David
 > is surely not interested in getting dragged into a license
 > discussion).

> It seems clear that *the* answer doesn't exist (not on google by any
> means), so the point of the question as I interpret it was about
> what your reasons are to refuse it.

I have already explained that LGPL is more restrictive than existing 
OpenC++ license (MIT-style). Mikolaj brings up valid arguments about 
LGPL complexity, also I treat Boost license rationale seriously.

> By the way, you asked for comments on potential licenses for future
> OpenCxx versions about a month ago. Was there any follow-up ?

Four persons responded, two of them in private e-mails (Hilde opted for 
Boost license, RodZilla would accept either of LGPL, MIT and Boost).

BR
Grzegorz

Re: [Opencxx-users] Bug in OpenC++: Preprocessor Parameters Ignored!

[Grzegorz J. <ja...@ac...>]

Marc,

Sorry for late response. This is a valid path, would you find time to 
apply it? If so, pls. send me you SF.net userid.

Best regards
Grzegorz

Marc Waeckerlin wrote:
> The following problem(s):
> 
>  - I built a compiler that should insert tracing information
>    into methods (function trace). The name is: trace
> 
>  - To compile my programs, I call:
>    ./trace -- -o xxx xxx.cxx
> 
>  - Now, my tracer needs the inclusion of file fntracer.hxx.
>    So I compile with:
>    ./trace -d-include -dfntrace.hxx -- -o xxx xxx.cxx
> 
> Problem:
> 
> The option "-include fntrace.hxx" is not passed to the 
> preprocessor. If I call ./trace -DX -- -o xxx xxx.cxx, this 
> is also not passed to the preprocessor, nor is any other 
> option, as -I and so on.
> 
> Solution:
> 
> One possible solution: Apply my patch.
> 
> My patch does the following:
> 
>  - Add a method to get the CC options to
>    OpencxxConfiguration
> 
>  - In file driver2.cc method RunPreprocessor, inserts the CC
>    options after argv.push_back(compiler)
> 
> That's it.
> 
> You can find my code in "opencxx-problem.tar.gz". There will 
> follow more mails on that subject later in this mailing 
> list...
> 
> Please fix this problem for the next release.
> 
> Thank's
> Marc
> 
> 
> ------------------------------------------------------------------------
> 
> diff -ur opencxx-2.8/opencxx/driver2.cc opencxx-patched/opencxx/driver2.cc
> --- opencxx-2.8/opencxx/driver2.cc	2004-08-10 09:48:05.000000000 +0200
> +++ opencxx-patched/opencxx/driver2.cc	2004-10-14 14:49:27.870216699 +0200
> @@ -241,9 +241,11 @@
>      string compiler = config.CompilerCommand();
>      
>      vector<string> argv;
> -    
> +
>      argv.push_back(compiler);
>  
> +    argv.insert(argv.end(), config.CppOptions().begin(), config.CppOptions().end());
> +
>      if(config.RecognizeOccExtensions())
>  	argv.push_back("-D__opencxx");
>      
> diff -ur opencxx-2.8/opencxx/MetacompilerConfiguration.h opencxx-patched/opencxx/MetacompilerConfiguration.h
> --- opencxx-2.8/opencxx/MetacompilerConfiguration.h	2004-08-10 09:48:05.000000000 +0200
> +++ opencxx-patched/opencxx/MetacompilerConfiguration.h	2004-10-14 14:42:21.060422444 +0200
> @@ -20,6 +20,7 @@
>  #include <opencxx/defs.h>
>  #include <string>
>  #include <memory>
> +#include <vector>
>  
>  namespace Opencxx
>  {
> @@ -95,7 +96,7 @@
>      virtual Opencxx::ErrorLog& ErrorLog() const = 0;
>      
>      virtual Iterator CcOptions() const = 0;
> -    
> +    virtual const std::vector<std::string>& CppOptions() const = 0;   
>      virtual Iterator Metaclasses() const = 0;
>  };
>  
> diff -ur opencxx-2.8/opencxx/OpencxxConfiguration.h opencxx-patched/opencxx/OpencxxConfiguration.h
> --- opencxx-2.8/opencxx/OpencxxConfiguration.h	2004-08-10 09:48:05.000000000 +0200
> +++ opencxx-patched/opencxx/OpencxxConfiguration.h	2004-10-14 14:42:32.511592506 +0200
> @@ -117,6 +117,9 @@
>      {
>          cc2Options_.push_back(option);
>      }
> +    const std::vector<std::string>& CppOptions() const {
> +      return cc2Options_;
> +    }
>      void SetDoPreprocess(bool v) { doPreprocess_ = v; }
>      bool DoPreprocess() const { return doPreprocess_; }
>      

Re: [Opencxx-users] "ChangeDefaultMetaclass" and "metaclass declaration"

[Grzegorz J. <ja...@ac...>]

Marc Waeckerlin wrote:
[...]
> I got a solution, even though it is not the best:
> 
> Before I trace anything, I check the filename and I don't 
> trace, if I am either in a file with absolute (not 
> relative) pathname or if i am in the tracer declaration:
> 
> int line;
> Opencxx::Ptree* fname
>   (env->GetLineNumber
>    (Opencxx::PtreeUtil::First(body), line));
> if (std::string(fname->ToString()).find('/')==0 ||
>     std::string(fname->ToString())=="fntrace.hxx")
>   return false;
> 
> Any idea for a better solution?

This one seems fine.

BR
Grzegorz

PS: You mentioned some problems with metaclass not being recognized 
despite -S option. Do you still have them? If so, could you post a 
minimal example?

> 
> Ok, to make it Windoze compatible, the "find" should 
> probably be changed to: find_first_of("/\\") and "fname" 
> could be instanciated as std::string instead of converting 
> it twice, but besides of minor enhancement, is there a 
> better, totally different approach?
> 
> 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

RE: [Opencxx-users] Re: [Synopsis-devel] constant expression analyzer and 'sizeof' and the recent license discussion

[<da...@te...>]

Hi Stefan,
The topic is not dead. It is beaten to death. The discussion 'which license
is better for the open source world' and 'should open source support
development of commercial software and closed source products' has VERY long
history. There are several opinions and this is mine:

Open source should support commercial software, closed software based on
open source projects. Why? Beacause it helps every programmer, every
software professional starting or joining small company, which has limited
(or literally none) resources. The professional can use the open source
products like: STL, boost (tokenizing, parsing, serializing,
dynamic-languages interface-to Python, C++ aids, math aids, graphs
operations, fast matrix operations, etc, etc), lua (the best, the easies to
integrate scripting language). Using it he jumps in no time into the so
called market. And here is the really important thing. The market.
In most cases, so called market is simply doing some additional work for
some particular client, one. The small company or even a loose group of
cooperating coders CAN NOT give the client the source code. I will say it
again: NO GIVING AWAY THE SOURCE CODE. Why? Because in that case the client
will gladly take another company and blackmail the original authors and make
them work for low price or (which is the case in eastern Europe) takes his
nephew or his friend who claims to code and has no job currently.

The client takes the code, and says: and now you will be my slave or I dump
you and take some other guys. 
Or: ok, you did good job, you did the hard part, but my nephew can code
either and he will get the rest of the contract, not you.

All of the ideas, all the most important work (which is interacting with
user, optimizing operations) which takes long and should give the authors
BIG advantage over the competitors is just gone. 

Ok, you will say that LGPL allows you to incorporate open source using
binaries. Here it is why it is not good:
1. Often you cannot do it that easly, or even VERY hard technically - there
are SO many examples, everyone can imagine at leas a few - I will say just
that it concerns mostly customizing open source products (like incorporating
OpenC++ into commercial editor, or giving additional features on clients
request)

2. The LGPL license is just HORRIBLE, no one can tell if particular use of
the product is legal or not - you cannot even trust a lawyer, because there
are only a few lawyers that specialize themselves in the subject (and they
are EXPENSIVE !!).

In the opposite, look at the OpenC++ licens which Grzegorz posted on the
list. It is SO simple that every manager will understand in 5 silly
minutes!! I cannot tell enough how important it is. 
Simply said: when the boss sees the LGPL license in the Synopsis readme, he
will say: get this out of my sight FAST, aaargh... 

And when he sees the OpenC++ Core license: cute thing, yes we need to do
some work to use it as we want, but we can own the code, and the competition
does not have it. And when we make the next step then we will post the code
to Grzegorz or support his team with a donation if we got succeeded.

Now some examples of great open source products allowing incorporating into
closed source products.
SGI STL - no comment: it is the fundament of C++ today
Boost- it is so big that it sould be here repeated 20 times 
Boost
Boost

OpenC++ - which I think will gain BIG attention after adding some more
features, liberal license will make it happen quicker (in my opinion)
Lua - www.lua.org, this is my favorite project :)
wxWidgets - my second favorite - "The wxWidgets 2 licence is essentially the

    L-GPL (Library General Public Licence), with an exception stating that 
    derived works in binary form may be distributed on the user's own terms"
quote from www.wxwidgets.org/newlicen.htm

I wish all of you who support the OpenC++ project best luck. I truly believe
that OpenC++Core will be major addition in the C++ world.

Best regards
Nick Dawidowski


-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Stefan
Seefeld
Sent: Wednesday, October 13, 2004 8:09 PM
To: 'Grzegorz Jakacki'; 'syn...@fr...'
Cc: ope...@li...
Subject: RE: [Opencxx-users] Re: [Synopsis-devel] constant expression
analyzer and 'sizeof'

Hey Grzegorz,

> From: Grzegorz Jakacki [mailto:ja...@ac...]
> Sent: October 12, 2004 07:12

> Pls. google for the answer, this subject has been beaten to 
> death many 
> times on different fora and seems to be religious issue, no point in 
> bringing it here.

The topic doesn't appear to be as dead as you make it sound
(as this very thread proves). May I remind you that you were the one
bringing the topic up, so all people are asking now is why you insist
on not wanting to use LGPL.
It seems clear that *the* answer doesn't exist (not on google by any
means), so the point of the question as I interpret it was about
what your reasons are to refuse it.
By the way, you asked for comments on potential licenses for future
OpenCxx versions about a month ago. Was there any follow-up ?

Regards,
		Stefan


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

[Opencxx-users] Use OpenC++ with autoconf / configure

[Marc W. <Mar...@si...>]

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.

Any other idea?

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++?

Thank you
Regards
Marc

Re: [Opencxx-users] "ChangeDefaultMetaclass" and "metaclass declaration"

[Marc W. <Mar...@si...>]

Am Donnerstag, 14. Oktober 2004 16.23 schrieb Marc 
Waeckerlin  <Marc Waeckerlin <Mar...@si...>> 
unter "[Opencxx-users] "ChangeDefaultMetaclass" and 
"metaclass declaration"":
> Possible solutions:
>
>  - Find a way to include fntrace.hxx as very first file
>
>  - Start OpenC++ metaclass instrumentation only after
>    inclusion of fntrace.hxx (i.e. with a "metaclass
>    declaration", by adding the line "metaclass
>    IsTraceClass;" as last line in header fntrace.hxx)
>
> The latter is exactly what I tried and why I send this
> error report.
>
> Any other idea?

I got a solution, even though it is not the best:

Before I trace anything, I check the filename and I don't 
trace, if I am either in a file with absolute (not 
relative) pathname or if i am in the tracer declaration:

int line;
Opencxx::Ptree* fname
  (env->GetLineNumber
   (Opencxx::PtreeUtil::First(body), line));
if (std::string(fname->ToString()).find('/')==0 ||
    std::string(fname->ToString())=="fntrace.hxx")
  return false;

Any idea for a better solution?

Ok, to make it Windoze compatible, the "find" should 
probably be changed to: find_first_of("/\\") and "fname" 
could be instanciated as std::string instead of converting 
it twice, but besides of minor enhancement, is there a 
better, totally different approach?

Regards
Marc

[Opencxx-users] design sketches

[Stefan S. <sse...@ar...>]

> From: SF Markus Elfring [mailto:el...@us...]
> Sent: October 5, 2004 01:18

> The summary about the Edward Willink's "Meta-Compilation for 
> C++" PhD thesis in the article "Parsing C++" shows more 
> design alternatives to structure this process into multiple 
> layers, phases, passes or stages.
> http://www.nobugs.org/developer/parsingcpp/


FWIW, here is a list of papers we currently look into to enhance
the parser:

* Symbol table construction and name lookup in ISO C++, 
  J. F. Power and B. A. Malloy,
  http://citeseer.ist.psu.edu/power00symbol.html

* An Approach for Modeling the Name Lookup Problem in the C++ Programming
Language, 
  James F. Power and Brian A. Malloy, 
  http://citeseer.ist.psu.edu/power00approach.html

* Decorating tokens to facilitate recognition of ambiguous language
constructs, 
  B. A. Malloy, J. F. Power and T. H. Gibbs, Software,
  http://www.cs.clemson.edu/~malloy/papers/papers.html

* The Design and Implementation of a Parser and Front-end for the ISO C++
Language and Validation of the Parser, 
  Tanton H.Gibbs, 
  http://www.cs.clemson.edu/~malloy/papers/papers.html

Also, there appears to be a GPLed C++ parser project available at 
http://sourceforge.net/projects/keystone/, which I'm going to look
into. One of the advantages OpenC++ has is its non-lossy storage
of the input, which makes it robust and less error-prone for code
generation (as you can modify specific places in the code and don't
need to regenerate the whole).

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.

Comments ?

Regards,
		Stefan

[Opencxx-users] "ChangeDefaultMetaclass" and "metaclass declaration"

[Marc W. <Mar...@si...>]

In the documentation, there is written under 
"ChangeDefaultMetaclass" (page 22 of the PDF):

"It should be called by Initialized() defined for a 
metaclass loaded loaded by the -S option at the beginning. 
Otherwise, that metaclass should be explicitely loaded by 
the metaclass declaration, after which the new metaclass is 
effective."

This does not work!

 - I don't use the "-S" option
 - I don't use any "metaclass" declaration

 -> But the metaclass is still applied!

Why?!?


Problem: 

At first sight, one would think that everything is ok. if 
the metaclass is loaded and applied, but unfortunately it 
is also applied to all to all system libraries, where I 
don't want it. That's why I need the "metaclass 
declaration" to be able to tell the OpenC++ processor where 
to start applying the metaclass.

How can I do this?


(You can check the opencxx-problem.tar.gz file of my 
previous mail for my implementation, it requires my patch).


What do I want to do:

 - Add a function trace to all my classes without changing
   a single line!

How do I try to do it:

 - Automatically include file "fntrace.hxx" by passing
   option "-include fntrace.hxx" to the C preprocessor

 - Make my trace class the new default class, so it is
   applied to all classes.

What's the problem with this approach:

 - All included system headers are also instrumented,
   means added a function trace

 - But the header fntrace.hxx is included later, so
   the symbols of that header are unknown before

Possible solutions:

 - Find a way to include fntrace.hxx as very first file

 - Start OpenC++ metaclass instrumentation only after
   inclusion of fntrace.hxx (i.e. with a "metaclass
   declaration", by adding the line "metaclass
   IsTraceClass;" as last line in header fntrace.hxx)

The latter is exactly what I tried and why I send this error 
report.

Any other idea?


Thank you
Regards
Marc

[Opencxx-users] Metaclass ignored without "using namespace Opencxx;"

[Marc W. <Mar...@si...>]

If I write a metaclass in a *.mc file and I use prefix 
Opencxx::* for all OpenC++ elements, then the metaclass is 
ignored.

But if I add the line "using namespace Opencxx;" in front of 
my file, everything works fine.

Why?!?

Thank you
Regards
Marc

[Opencxx-users] Bug in OpenC++: Preprocessor Parameters Ignored!

[Marc W. <Mar...@si...>]

The following problem(s):

 - I built a compiler that should insert tracing information
   into methods (function trace). The name is: trace

 - To compile my programs, I call:
   ./trace -- -o xxx xxx.cxx

 - Now, my tracer needs the inclusion of file fntracer.hxx.
   So I compile with:
   ./trace -d-include -dfntrace.hxx -- -o xxx xxx.cxx

Problem:

The option "-include fntrace.hxx" is not passed to the 
preprocessor. If I call ./trace -DX -- -o xxx xxx.cxx, this 
is also not passed to the preprocessor, nor is any other 
option, as -I and so on.

Solution:

One possible solution: Apply my patch.

My patch does the following:

 - Add a method to get the CC options to
   OpencxxConfiguration

 - In file driver2.cc method RunPreprocessor, inserts the CC
   options after argv.push_back(compiler)

That's it.

You can find my code in "opencxx-problem.tar.gz". There will 
follow more mails on that subject later in this mailing 
list...

Please fix this problem for the next release.

Thank's
Marc

[Opencxx-users] Re: Opencxx-users -- confirmation of subscription -- request 808652

[Marc W. <Mar...@si...>]

Am Donnerstag, 14. Oktober 2004 14.05 schrieb=20
ope...@li... =20
<ope...@li...> unter=20
"Opencxx-users -- confirmation of subscription -- request=20
808652":
> Opencxx-users -- confirmation of subscription -- request
> 808652
>
> We have received a request from 194.204.64.99 for
> subscription of your email address,
> <mar...@si...>, to the
> ope...@li... mailing list.  To
> confirm the request, please send a message to
> ope...@li..., and either:
>
> - maintain the subject line as is (the reply's additional
> "Re:" is ok),
>
> - or include the following line - and only the following
> line - in the message body:
>
> confirm 808652
>
> (Simply sending a 'reply' to this message should work
> from most email interfaces, since that usually leaves the
> subject line in the right form.)
>
> If you do not wish to subscribe to this list, please
> simply disregard this message.  Send questions to
> ope...@li....

=2D-=20
Siemens Schweiz AG, I-49/606
Marc W=E4ckerlin, System Ingenieur
Albisriederstrasse 245, CH-8047 Z=FCrich
Telefon: ++41 58 558 32 29
mailto:mar...@si... http://www.siemens.ch/es

++++ E-Mail Guidelines: email.waeckerlin.org ++++

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[David A. <dav...@rc...>]

Stefan Seefeld <sse...@ar...> writes:

> Hey Grzegorz,
>
>> From: Grzegorz Jakacki [mailto:ja...@ac...]
>> Sent: October 12, 2004 07:12
>
>> Pls. google for the answer, this subject has been beaten to 
>> death many 
>> times on different fora and seems to be religious issue, no point in 
>> bringing it here.
>
> The topic doesn't appear to be as dead as you make it sound
> (as this very thread proves). May I remind you that you were the one
> bringing the topic up, so all people are asking now is why you insist
> on not wanting to use LGPL.
> It seems clear that *the* answer doesn't exist (not on google by any
> means), so the point of the question as I interpret it was about
> what your reasons are to refuse it.
> By the way, you asked for comments on potential licenses for future
> OpenCxx versions about a month ago. Was there any follow-up ?

FWIW, the reasons that Boost doesn't accept LGPL are at
http://tinyurl.com/7x86d

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

RE: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[Stefan S. <sse...@ar...>]

Hey Grzegorz,

> From: Grzegorz Jakacki [mailto:ja...@ac...]
> Sent: October 12, 2004 07:12

> Pls. google for the answer, this subject has been beaten to 
> death many 
> times on different fora and seems to be religious issue, no point in 
> bringing it here.

The topic doesn't appear to be as dead as you make it sound
(as this very thread proves). May I remind you that you were the one
bringing the topic up, so all people are asking now is why you insist
on not wanting to use LGPL.
It seems clear that *the* answer doesn't exist (not on google by any
means), so the point of the question as I interpret it was about
what your reasons are to refuse it.
By the way, you asked for comments on potential licenses for future
OpenCxx versions about a month ago. Was there any follow-up ?

Regards,
		Stefan

Re: [Opencxx-users] install tweek for pkgconfig

[Grzegorz J. <ja...@ac...>]

Yann Dirson wrote:
> In toplevel Makefile.am we have the following:
> 
> install-data-local:
>         if test -d $(libdir)/pkgconfig; then \
>           mkdir -p $(DESTDIR)$(libdir)/pkgconfig; \
>           cp -p opencxx.pc $(DESTDIR)$(libdir)/pkgconfig; fi
> 
> I'm not sure it is a good idea to for $(libdir)/pkgconfig.  When
> building a package, for example, there may not be a pkgconfig dir on
> the builder's machine, but we still want it to get into the package.
> 
> Since it is a small file anyway, I suggest we just install it
> unconditionally, and to the same for other small support files of this
> kind.  No objections ?

No objections. (Sorry for the late answer, I was traveling.)

BR
Grzegorz

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> Hi Eric,
> 
> I forward this to the OpenCxx list as that's where you'll have better
> chances to find an answer to your questions...
> 
> Eric Hopper wrote:
> 
> 
>>On Thu, Sep 30, 2004 at 01:41:37AM +0800, Grzegorz Jakacki wrote:
>>
>>
>>>LGPL has drawbacks, please consider the fact that Boost has rejected
>>>it.
>>
>>
>>What are the drawbacks, aside from the fact that it vexes companies who
>>would like to keep all of their source code secret?  Is there a reason
>>that particular vexation is actually bad for anybody besides the company
>>who's chafing against it?

Pls. google for the answer, this subject has been beaten to death many 
times on different fora and seems to be religious issue, no point in 
bringing it here.

BR
Grzegorz

RE: [Opencxx-users] YASQ (yet another stupid question...)

[Stefan S. <sse...@ar...>]

Hi rodzilla,

> From: RodZilla [mailto:rod...@fr...]
> Sent: October 5, 2004 08:50

> IIRC this will be my third stupid question.
> Is it possible to obtain the declaration of a variable from
> a (ptree of a) reference ? I started looking at Environment
> and Bind classes, but it seems I can get the type but not the
> Ptree for the declaration.

FWIW, symbol lookup as well as the (re)definition of what
a Symbol (Binding) contains is what we are currently working
on in Synopsis, see http://synopsis.fresco.org/issues/task25 .

In the high level Synopsis AST API I provide a 'Type' hierarchy
with a subclass 'Declared'. All declared types contain a reference
to their respective declaration.

I agree the same should be done in the lower level PTree API.

Regards,
		Stefan

[Opencxx-users] YASQ (yet another stupid question...)

[RodZilla <rod...@fr...>]

Hi all,

IIRC this will be my third stupid question.
Is it possible to obtain the declaration of a variable from
a (ptree of a) reference ? I started looking at Environment
and Bind classes, but it seems I can get the type but not the
Ptree for the declaration.
Thanx a lot in advance.

Best regards,

Rod.

Re: [Opencxx-users] ANN: OpenC++ Core, C++ introspection library -- snapshots available

[SF M. E. <el...@us...>]

> [...] I put a lot of work into cleaning up and refactoring
> the code, and I'v been making important progress over the last
> couple of weeks, in particular with symbol lookup and const expression
> evaluation that has to take place *during* the parsing, not in a second
> phase, to help the parser disambiguate certain expressions (templates,
> type lookup and overloading).
> [...]

The summary about the Edward Willink's "Meta-Compilation for C++" PhD thesis in the article "Parsing C++" shows more design alternatives to structure this process into multiple layers, phases, passes or stages.
http://www.nobugs.org/developer/parsingcpp/

Regards,
Markus

[Opencxx-users] install tweek for pkgconfig

[Yann D. <yd...@us...>]

In toplevel Makefile.am we have the following:

install-data-local:
        if test -d $(libdir)/pkgconfig; then \
          mkdir -p $(DESTDIR)$(libdir)/pkgconfig; \
          cp -p opencxx.pc $(DESTDIR)$(libdir)/pkgconfig; fi

I'm not sure it is a good idea to for $(libdir)/pkgconfig.  When
building a package, for example, there may not be a pkgconfig dir on
the builder's machine, but we still want it to get into the package.

Since it is a small file anyway, I suggest we just install it
unconditionally, and to the same for other small support files of this
kind.  No objections ?

Best regards,
-- 
Yann Dirson    <yd...@al...> |
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[Stefan S. <sse...@ar...>]

Hi Eric,

I forward this to the OpenCxx list as that's where you'll have better
chances to find an answer to your questions...

Eric Hopper wrote:

>On Thu, Sep 30, 2004 at 01:41:37AM +0800, Grzegorz Jakacki wrote:
>
>>LGPL has drawbacks, please consider the fact that Boost has rejected
>>it.
>
>
>What are the drawbacks, aside from the fact that it vexes companies who
>would like to keep all of their source code secret?  Is there a reason
>that particular vexation is actually bad for anybody besides the company
>who's chafing against it?

Re: [Opencxx-users] ANN: OpenC++ Core, C++ introspection library -- snapshots available

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:

> All comments on the design and implementation, as well as feature
> requests, are welcome. Feel free to post them to
> opencxx-users(at)lists.sourceforge.net .

before I send more comments I'd very much appreciate some discussion
on my previous mails. Did anybody have a look into my alternative
design ?

Also, as people on this list may not be aware of this discussion:
Grzegorz and I have been discussing whether it would be possible to
'join forces', i.e. develop Synopsis and OpenC++ together. Beside
the license discussion that generated quite a bit of noise there
were other points we discussed such as where such a development
should take place.
I suggested that development takes place inside the synopsis project,
for basically two reasons:

* I consider the infrastructure synopsis uses to be more advanced
   compared to OpenC++'s own (from the subversion tool over the issue
   tracker up to the qmtest unit testing framework)

* I consider the synopsis code base to be a better starting point [*]
   for future work. I put a lot of work into cleaning up and refactoring
   the code, and I'v been making important progress over the last
   couple of weeks, in particular with symbol lookup and const expression
   evaluation that has to take place *during* the parsing, not in a second
   phase, to help the parser disambiguate certain expressions (templates,
   type lookup and overloading).

I sincerely hope that even if our differences remain unsolvable to
allow us to fully join the projects we are still able to collaborate
in some way to understand the design issues both projects have to face
if we want to provide high quality tools.

Kind regards,
		Stefan

[*] I invite everybody to have a look into synopsis' C++ parser that
     is based on  an OpenC++ version from about four years ago, and then
     evolved more or less independently:
     http://synopsis.fresco.org/viewsvn/synopsis-Synopsis/trunk/Synopsis/Parsers/Cxx/occ/

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression analyzer and 'sizeof'

[Grzegorz J. <ja...@ac...>]

Hi Stefan,

David Abrahams wrote:
> Stefan Seefeld <sse...@ar...> writes:
> 
> Even though it's a big job, it would be a great service to the C++
> community.  I could probably find people to help you with it.

I have already made this plea, and we have already had a discussion on 
opencxx-users, but let me try again.

Stefan, please reconsider relicensing your C++ introspection code under 
license less restrictive than LGPL.

This code was derived from OpenC++, and as you and me agreed, it would 
benefit both projects if this code could be reused and, ideally, shared.
Unfortunately, due to the fact that your code is under LGPL, your 
contribution cannot be merged into OpenC++, without disturbing its less 
restrictive license.

LGPL has drawbacks, please consider the fact that Boost has rejected it.

Currently OpenC++Core subproject within OpenC++ is working towards goal 
of creating C++ introspection and refactoring library. We were 
discussing it a lot, and you know that both your efforts and OpenC++ 
Core could benefit from cooperation.

Please reconsider relicensing your C++ introspection code under license 
as lax as OpenC++ license or Boost Software License.

Still hoping for cooperation
Grzegorz

[Opencxx-users] ANN: OpenC++ Core, C++ introspection library -- snapshots available

[Grzegorz J. <ja...@ac...>]

Hi All,

OpenC++ Core is introspection and refactoring library providing C++ 
lexer, parser and type evaluator.

OpenC++ Core, being a work in progress, is alreay usable for many 
purposes (e.g. finding classes and member signatures). Shapshots are 
available from

     http://opencxx.sourceforge.net/occ-core

The ultimate goal of OpenC++ Core is to enable clients to modify the
in-memory representation of C++ code and write it back to source files.
OpenC++ Core is not there yet, but given the fact that similar 
functionality exists already in the code inherited from OpenC++ 
framework, this goal seems to be reachable.

All comments on the design and implementation, as well as feature
requests, are welcome. Feel free to post them to
opencxx-users(at)lists.sourceforge.net .

Best regards
Grzegorz

Re: [Opencxx-users] Re: [Synopsis-devel] constant expression anal yzer and 'sizeof'

[David A. <da...@bo...>]

Stefan Seefeld <sse...@ar...> writes:

> Hi David,
>
> David Abrahams wrote:
>
>>  sizeof(char) == 1
>>  sizeof(char[2]) == 2
>>  sizeof(char(&)[2]) == 2
>>  sizeof(char[3]) == 3
>>  sizeof(X[N]) == N * sizeof(X)
>>
>>There are programs that rely on these relationships.
>
> This is the kind of invariants I'm looking for, thanks !
>
>>You're going to need to build in full overload resolution and
>>template instantiation capability, which is no small job.
>
> [...]
>
>>Even though it's a big job, it would be a great service to the C++
>>community.  I could probably find people to help you with it.
>
> That would be more than welcome. I'm currently refactoring
> the C++ parser code adding support for this kind of analysis.
> Progress can be tracked via the various unit tests I'm putting
> into place.
>
> I'd very much appreciate any help I could get in defining
> what exactly needs to be done, and of course, in designing and
> implementing it.

Why don't you put out a call for volunteers on the boost-devel list?  I
will immediately follow up with an endorsement.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com