Hi,
In the User's list, Jeff mentioned generating the windows flex code
during make dist time, I didn't think about it before, it should work if
flex is newer than 2.5.4 (the latest version is 2.5.35).
In the created tarball, the flex generated c source won't compile under
Windows, that's because using an old version of flex, the generated file
include unistd.h but there is no way to exclude it. The newer flex
generate output file with following code piece:
#ifndef YY_NO_UNISTD_H
/* Special case for "unistd.h", since it is non-ANSI. We include it way
* down here because we want the user's section 1 to have been scanned
first.
* The user has a chance to override it with an option.
*/
#include <unistd.h>
#endif
So that on the platforms that don't have unistd.h, just define
'YY_NO_UNISTD_H' to get rid of it.
Updating the flex that used for make dist, will be the best solution to
remove flex.exe from the tarball. But this windows flex.exe should be
better remain in svn repository for svn checkout build.
Thanks,
Shiqing
Ralph Castain wrote:
Let's shift this to the devel mailing list and add it to the Tues telecon.
Thanks for clarifying. Sounds to me like the suggestions made below are right -
we shouldn't be distributing binary in the main tarball for export reasons.
Seems like we have four options:
1. A separate Windows-tool tarball
2. remove flex from the 3-4 places it is used in the code base and replace it
with something that doesn't have this requirement. We don't use that much text
processing - it may not take that much effort to write our own utility for this
purpose.
3. not use the features that are missing from the windows version.
4. even though it changes sometimes, generate the flex-code output and ship it
like we used to do
Regardless, shipping binary in a source tarball seems like a really bad idea in
this age of viral concerns.
On Jan 22, 2010, at 3:09 AM, Shiqing Fan wrote:
Hi,
flex.exe is not generated at compile time, but flex.exe has to be used to
generate those *flex*.c files during compilation, like show_help_lex.c (a.k.a
the flex-generated code).
The windows binary of flex on sourceforge doesn't fit the requirement of Open
MPI, it has some missing features. That's why we have to compile a new flex.exe
for Windows, and put it in the source tree.
Regards,
Shiqing
Ralph Castain wrote:
Maybe I'm misunderstanding, but if it is generated at -compile- time, then how
did it get in the 1.4.1 tarball?
On Jan 22, 2010, at 1:56 AM, Shiqing Fan wrote:
Hi,
No, that's not true, we did ship the flex-generated code a time ago, but as
that part of code changes sometimes, we decided to generate it during
compilation time, and the flex.exe came with the first support of Windows
(CMake).
Regards,
Shiqing
Jeff Squyres wrote:
Don't we ship the flex-generated code in the tarball anyway? If so, why do we
ship flex.exe?
On Jan 21, 2010, at 12:14 PM, Barrett, Brian W wrote:
I have to agree with the two requests here. Having either a windows tarball or
a windows build tools tarball doesn't seem too burdensom, and could even be
done automatically at make dist time.
Brian
----- Original Message -----
From: users-boun...@open-mpi.org <users-boun...@open-mpi.org>
To: us...@open-mpi.org <us...@open-mpi.org>
Sent: Thu Jan 21 10:05:03 2010
Subject: Re: [OMPI users] flex.exe
Am Donnerstag, den 21.01.2010, 11:52 -0500 schrieb Michael Di Domenico:
openmpi-1.4.1/contrib/platform/win32/bin/flex.exe
I understand this file might be required for building on windows,
since I'm not I can just delete the file without issue.
However, for those of us under import restrictions, where binaries are
not allowed in, this file causes me to open the tarball and delete the
file (not a big deal, i know, i know).
But, can I put up a vote for a pure source only tree?
I'm very much in favor of that since we can't ship this binary in
Debian. We'd have to delete it from the tarball and repack it with every
release which is quite cumbersome. If these tools could be shipped in a
separate tarball that would be great!
Best regards
Manuel
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
--------------------------------------------------------------
Shiqing Fan http://www.hlrs.de/people/fan
High Performance Computing Tel.: +49 711 685 87234
Center Stuttgart (HLRS) Fax.: +49 711 685 65832
Address:Allmandring 30 email: f...@hlrs.de 70569 Stuttgart
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
--------------------------------------------------------------
Shiqing Fan http://www.hlrs.de/people/fan
High Performance Computing Tel.: +49 711 685 87234
Center Stuttgart (HLRS) Fax.: +49 711 685 65832
Address:Allmandring 30 email: f...@hlrs.de 70569 Stuttgart
--
--------------------------------------------------------------
Shiqing Fan http://www.hlrs.de/people/fan
High Performance Computing Tel.: +49 711 685 87234
Center Stuttgart (HLRS) Fax.: +49 711 685 65832
Address:Allmandring 30 email: f...@hlrs.de
70569 Stuttgart
