Subject: Re: thoughts about including PCCTS header files?
From: Magnus Danielson (cfmd@swipnet.se)
Date: Fri Nov 09 2001 - 16:00:22 MST
From: Dale E Martin <dmartin@cliftonlabs.com>
Subject: thoughts about including PCCTS header files?
Date: Fri, 9 Nov 2001 11:09:45 -0500
> Hello!
Hi Dale,
> I had an issue that came up with a user that I wanted to discuss
> with the other SAVANT developers.
>
> When we build a distribution via "make dist", part of what is included in
> that distribution is the code generated by flex and antlr. This is a good
> thing because it potentially decreases the tool burden on the end-user; in
> theory all they need is a c++ compiler to build and install.
I think they need a shell and make, but anyway, theory is nice ;O)
> This is only partially true though; the code generated by both flex and
> antlr #includes some stuff distributed with those tools. So they do have
> to have those headers to compile, even if we ship generated code. Another
> issue is that there have been changes to the generated code that makes it
> so that if you've got an older version of the PCCTS header files, you can't
> build out of the box.
Indeed a problem. You want header files which matches those of the
flex and antlr that you actually used when generating the files.
> This is because the code distributed was emitted by a new version, and even
> if you have antlr installed, the code that's distributed is compiled. So
> if there's a header file mismatch, the compile bombs.
Right.
> Here are some proposed solutions:
> 1) Ship the PCCTS and flex headers with the SAVANT archive. There is also
> a small amount of .cpp code from PCCTS that we compile from the PCCTSROOT
> dir - we could ship that too.
>
> Doing all of this should eliminate the need for the PCCTSROOT environment
> variable.
I think this is a fair solution. It falls upon the maintainers of
Savant to come up with methods of handling it, as long as we ensure
that there is not external dependence.
> 2) Don't ship generated code. Force the user to have PCCTS and flex
> installed if they want to build.
For me, a nut-case for a developer which allready have these tools
installed since a long time, it would not be a problem.
If I take on a more serious attitude, i'd say that these tools can not
be assumed. Flex has spreading, but on many platforms it is still not
a standard development tool, so it can't safely be assumed. As for
PCCTS, which contains antlr, I'd say that it is not as well spread as
it deserves (forget YACC and BISON, look at PCCTS instead, which is
better for most applications IMHO) you can not really assume it at
all.
If we want to make users happy and start using it, having to
install more or less esoteric tools (said with the naive user hat on)
just to compile is not the solution.
Thus, I think this is the worst solution.
> 3) Ship the generate code; however, if flex/antlr is found, then
> automagically regenerate the relevant files. This sounds appealing, but
> currently there is no official version of flex that generates code accepted
> by g++ 3.0. The Debian package does, because I submitted a patch to Debian
> to fix the problem. This patch went upstream but last time I checked it
> had not been integrated into the upstream version.
I think that this is the ideal middle way, which will satisfy
most. Problem is the compatibility issues, having to check version of
various tools and mix them together. No, I don't think this is a very
nice thing to have (the version checking mess).
In the end, alternative 3 could be viewed good since it matched the
needs of a random user (does not have to use the esoteric development
tools) vs. that of a developer. The downside is the inter-compability
issues and it can take years to safely clean out such checks once
introduces, just because some people run old installations.
If we take into considerations that all the developers I know is
active have CVS access, they do not depend on the result of a "make
dist". However, this is also sad, since this does not make the
distribution format issues a daily concern :-/
So, in practice I think that alternative 1 is the winner. I am sure we
can cook up a solution which automagically includes the files into a
suitable library at the time of "make dist".
You did not bring up the alternatives of actually including the tool
source-code in the distribution, which is an alternative too, but an
ugly one.
> Any thoughts about this?
You bet!
> Long term I'd like to get rid of all of the "<X>ROOT" environment
> variables, and go with a more standard "CPPFLAGS=" type build...
Yes, we should get rid of all those ROOT variables, but CPPFLAGS many
not be the best method either. However, that is another issue. Getting
rid of unnecessary environment variables for compile would be a great
step forward, just shifting to another set is not as good.
Cheers,
Magnus
This archive was generated by hypermail 2b25 : Mon Mar 18 2002 - 13:00:02 MST