Maik Beckmann wrote:
The _second_ option proposed in the book is to have two distinct fortran
lexers (and probably two parsers). This is the cleanest solution, but would
be engineered for this special problem, IMHO.
Fixed and free format are practically two different languages from the
Brad King schrieb am Montag 16 März 2009 um 14:24:
Maik Beckmann wrote:
The _third_ option is to make the lexer format agnostic and handle
formats at the parser code. This should work well, since we just have to
make sure that the valid MODULE und USE statements are catched. Remeber,
so
Maik Beckmann wrote:
Brad King schrieb am Montag 16 März 2009 um 14:24:
Maik Beckmann wrote:
The _third_ option is to make the lexer format agnostic and handle
formats at the parser code. This should work well, since we just have to
make sure that the valid MODULE und USE statements are
Brad King schrieb am Montag 16 März 2009 um 15:06:
CALL FOO() ; MODULE mymod ! crazy, but possible
Damn, you are right.
Perhaps it is simplest to use the file extension as a heuristic for now.
At least some compilers require special flags to build .f as free format.
If this becomes a real
Maik Beckmann wrote:
I still didn't test whether fixed format file can include a free format file,
or vise versa. In this case having distinct lexers(and parsers?) is the only
reliable approach.
I just tried these cases and gcc chokes on both cases:
! main-free.f90
include 'fixed.f'
!
Brad King schrieb am Montag 16 März 2009 um 15:48:
Maik Beckmann wrote:
I still didn't test whether fixed format file can include a free format
file, or vise versa. In this case having distinct lexers(and parsers?)
is the only reliable approach.
I just tried these cases and gcc chokes
Maik Beckmann schrieb am Samstag 14 März 2009 um 00:02:
However, a look at cmFortranLexer.cxx shows that BEGIN is defined as
#define BEGIN yyg-yy_start = 1 + 2 *
which IMHO means that the lexer can only have one state at a time. If
str_dq or str_sq is set, the desired *_fmt state is lost.
Dear CMake list subscripers,
I have a project with verious ADD_LIBRARY/ADD_EXECUTABLE targets in different
subdirectories. Some of these targets depend on mico corba, some don't. As well
as some depend on libxml2, some don't.
We have developers working on sub-projects, which do not require
Denis Scherbakov wrote:
Dear CMake list subscripers,
I have a project with verious ADD_LIBRARY/ADD_EXECUTABLE targets in
different subdirectories. Some of these targets depend on mico corba,
some don't. As well as some depend on libxml2, some don't.
We have developers working on
I don't understand the question here? At gmake time
why do they need to know anything about mico or libxml2?
Ok, I will try harder now:
Let's say I have a main CMakeLists.txt and 2 sub projects:
=CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.1 FATAL_ERROR)
Bill Hoffman wrote:
The following Fortran code cannot be compiled with CMake, because
CMake looks for module called name, which of course, does not exist.
Actually it thinks the source is defining a module called name.
If I replace Module with _Module_ the code compiles.
Hi Denis,
If only project SOMENAME in directory targetA depends on LibXml2, then
you should move the line INCLUDE(FindLibXml2) to the file
targetA/CMakeLists.txt.
BTW, I'd prefer to use find_package(LibXml2), but that may be a matter
of taste.
Best regards,
Marcel Loose.
On Fri, 2009-03-13 at
Dear Marcel Loose,
I tried what you have suggested and it doesn't work also.
Here is what I have:
=CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.1 FATAL_ERROR)
ADD_SUBDIRECTORY(printf)
ADD_SUBDIRECTORY(puts)
ADD_SUBDIRECTORY(forbug)
SET(MAIN_SRCS
main.cpp)
2009/3/13 Denis Scherbakov denis_scherba...@yahoo.com:
As I already wrote, my problem is that IF ( NOT MICO_FOUND ) code is
executed too early - during compilation by cmake, not when user types gmake
puts and it becomes clear that MICO is needed.
That's the expected behavior, because CMake
2009/3/13 Eric Noulard eric.noul...@gmail.com:
My statement was ambiguous:
cmake -DBUILD_PRINTF:BOOL=OFF
The previous line is meant to avoid building the PRINTF project
while...
in this case the default is to build both.
The default value of options
BUILD_PRINTF
BUILD_PUTS
is to build
Eric,
Your solution requires a developer to know too much about the project, which is
not always true and basically to answer a full-scale questionnaire before
compilation. What if it is a new developer? What if it is not a developer, but
a user who expects everything to compile
Denis Scherbakov wrote:
Eric,
Your solution requires a developer to know too much about the
project,
which is not always true and basically to answer a full-scale
questionnaire before compilation. What if it is a new developer? What if
it is not a developer, but a user who expects everything
Brad King schrieb am Freitag 13 März 2009 um 16:51:
Actually, I cannot tell from a quick glance at the code how it ignores
'USE' keywords that appear after a ';' separator. It does not ignore
'MODULE' after ';'. Maik?
If a piece of code is identifed by the _lexer_ as being a comment, it is
2009/3/13 Denis Scherbakov denis_scherba...@yahoo.com:
Eric,
Your solution requires a developer to know too much about the project, which
is not always true and basically to answer a full-scale questionnaire before
compilation. What if it is a new developer?
If it is not a developer there
2009/3/13 Maik Beckmann beckmann.m...@googlemail.com:
Brad King schrieb am Freitag 13 März 2009 um 16:51:
Actually, I cannot tell from a quick glance at the code how it ignores
'USE' keywords that appear after a ';' separator. It does not ignore
'MODULE' after ';'. Maik?
If a piece of code
Eric Noulard schrieb am Freitag 13 März 2009 um 19:00:
which makes me think that ALL fixed_fmt rules in the lexer are
currently ignored
because the start condition never gets activated.
i.e. there should be some code that's tell the lexer that it is lexing
a fixed format file.
Note that
Brad King schrieb am Freitag 13 März 2009 um 16:51:
The full fix is of course to discard 'C'-prefixed comments completely,
but that can only be done in fixed-form sources. Currently our lexer
has code to support fixed-form files but it is never enabled. CMake
does not know whether a source
22 matches
Mail list logo
