fenics team mailing list archive

["tomtzigt" <tomtzigt@xxxxxxxxxxxxxxxx>]

That's very true. Judicious selection of STL functionality could get around
many of the old C-isms that evolved differently in Unix and Windows land.
Being a math library 'we' should be able to be very clean and portable.

Did we talk about using BOOST at the FEniCS workshop? There is a lot of
functionality in those libraries, and they are effectively working libs for
inclusion in the new C++ standard libraries and thus great candidates to
leverage.

I'll do the issue reporting right now.

Theo

-----Original Message-----
From: Anders Logg [mailto:logg@xxxxxxxxx] 
Sent: Sunday, December 11, 2005 5:01 PM
To: tomtzigt; Discussion of FEniCS development
Subject: Re: [fenics-dev] MSVC version of FEniCS

It looks like most of these issues can be fixed without having to find
"windows alternatives". We can probably avoid using unistd.h, we
should use std::string and avoid having to ever use strcasecmp etc.

I'll take a closer look in a day or two and try to fix some of the
problems.

It would be great if you could report the issues individually (to
dolfin-dev@xxxxxxxxxx) since that would make it easier to track and
follow up.

/Anders


On Sun, Dec 11, 2005 at 11:18:15AM -0500, tomtzigt wrote:
> Enclosed are the pending issues. The simple ones are on top:
> Header uninst.h is equivalent to io.h (at least in Windows and MinGW)
> Header sys/utsname.h seems superfluous
> 
> Strcasecmp is used in Linux, stricmp in Windows. So replaced with macro
that
> changes name depending on platform.
> 
> 
> 
> Theo
> 
> 
> -----Original Message-----
> From: Anders Logg [mailto:logg@xxxxxxxxx] 
> Sent: Saturday, December 10, 2005 9:43 PM
> To: tomtzigt; Discussion of FEniCS development
> Subject: Re: [fenics-dev] MSVC version of FEniCS
> 
> Could you give any specifics? Which packages have you tried to
> compile? Maybe some of the problems you have spotted are not
> Unix-specific, only non-standard, and then it would be good to know so
> we could fix.
> 
> /Anders
> 
> 
> On Sat, Dec 10, 2005 at 08:21:54PM -0500, tomtzigt wrote:
> 
> > Actually, the more pressing desire is to run with the MS compilers and
> IDE.
> > I have MinGW and FEniCS compiles with it, although I haven't tried to
> > compile PETSc with it to complete the FEniCS stack, but I am sure I can
> make
> > that work.
> > 
> > What I'll do is try is isolate the problem headers in a clean way, that
> is,
> > move some of the sys headers that Windows doesn't share, into a single
> > include file that accumulates the compiler and platform testing logic.
> This
> > doesn't mess up the code with ifdefs all over the place and is a central
> > place where any portability issues can be addressed. The only
disadvantage
> > is that this header can become a small compilation time drain on the
> overall
> > build since it wouldn't be the leanest meanest header you could create.
> Not
> > a big problem for MS environment with precompiled headers, but typically
> > less attractive for gcc that doesn't have precompiled headers; it all
> > depends on how pervasive the OS specific features are that are included
> and
> > of what I see that is small. When that portability layer becomes larger
> the
> > right way to deal with it is to compile it into its own library and
> > associated abstractions.
> > 
> > Theo
> > 
> > -----Original Message-----
> > From: Anders Logg [mailto:logg@xxxxxxxxx] 
> > Sent: Friday, December 09, 2005 11:27 PM
> > To: tomtzigt; Discussion of FEniCS development
> > Subject: Re: [fenics-dev] MSVC version of FEniCS
> > 
> > On Fri, Dec 09, 2005 at 08:54:43PM -0500, tomtzigt wrote:
> > >    Guys:
> > > 
> > > 
> > > 
> > >     I decided to see if I can transmogrify FEniCS into something that
> > MSDev
> > >    .NET understands. I am successfully building many of the kernel
> > projects
> > >    but in getting this to work I see a handful of Unixisms that will
> never
> > >    port to Windows natively.
> > 
> > Anything specific you think of?
> > 
> > If for some reason you insist on running on Windows, I suggest using
> > Cygwin which at least gives you a Unix-like environment.
> > 
> > > The typical way to deal with this is to have
> > >    some standard
> > > 
> > > 
> > > 
> > >    #ifdef LINUX_GNU
> > > 
> > >    #include <woopdido>
> > > 
> > >    #elsif WINDOWS
> > > 
> > >    #include <woopdida>
> > > 
> > >    #endif
> > > 
> > > 
> > > 
> > >    constructs in the headers which I can hack into the code in a fine
> way
> > and
> > >    a not so fine way. So I am trying to gauge if native windowness
using
> > the
> > >    MS compilers is desired by many or just me.
> > 
> > It's nothing I desire, but I'm not opposed to it. It could bring some
> > advantages, such as forcing us to follow standards which will also
benefit
> > other platforms.
> > 
> > >    If it is the latter then I
> > >    won't try to solve this problem neatly. If the larger community is
> > >    interested, I can solve it nicely.
> > > 
> > > 
> > > 
> > >    Opinions?
> > > 
> > > 
> > > 
> > >    Theo
> > 
> > Any suggestions are welcome. I have never built anything on Windows
> > (except under Cygwin) so the whole Windows platform is a mystery to
> > me.
> > 
> > /Anders
> > 
> > 
> > 
> > 
> 

> header unistd.h maps (roughly) to io.h
> 	places: Logger.cpp
> 
> #ifdef WINDOWS
> #define STRCASECMP(X,Y)  stricmp(X,Y)
> #else
> #define STRCASECMP(X,Y)  strcasecmp(X,Y)
> #endif
> 
> header sys/utsname.h
> 
> 
> files modified:
> kernel/settings/ParameterList.cpp
> 	header sys/utsname.h	// commented it out
> kernel/log/Logger.cpp
> 	header uninst.h		// replaced with io.h and STRCASECMP check
> kernel/settings/dolfin/Settings.h
> 	added header <limits> to bring in numeric_limit
> 
> List of current issues:
> math makes reference to srand48 et. al., need to find the Windows
equivalents.
> 
> 
> PArray is not compiling for some unknown reason
> Compiling...
> Form.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : warning C4346:
'dolfin::PArray<T>::Iterator::__ctor' : dependent name is not a type
>         prefix with 'typename' to indicate a type
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : error C2143: syntax error : missing ';' before
'&'
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : error C2350:
'dolfin::PArray<T>::Iterator::__ctor' is not a static member
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(446) : error C2065: 'T' : undeclared identifier
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(446) : error C2955: 'dolfin::PArray' : use of class
template requires template argument list
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(187) : see declaration of 'dolfin::PArray'
> 
> 
> In kernel/function some thing:
> Compiling...
> Function.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : error C2143: syntax error : missing ';' before
'&'
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : error C2350:
'dolfin::PArray<T>::Iterator::__ctor' is not a static member
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\c
ommon\dolfin\PArray.h(445) : fatal error C1903: unable to recover from
previous error(s); stopping compilation
> 
> In kernel/log, problems with operator<< LogStream->Parameter not being
defined:
> Compiling...
> Progress.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
> Logger.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
> 
> In kernel/settings, same problem with operator<<:
> Compiling...
> ParameterList.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
> Parameter.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\Parameter.cpp(67) : warning C4800: 'int' : forcing value to bool
'true' or 'false' (performance warning)
> SettingsManager.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
> SettingsMacros.cpp
>
c:\Development\oss\src\Applications\FEniCS\dolfin\dolfin-0.5.10\src\kernel\s
ettings\dolfin\Parameter.h(64) : error C2039: '<<' : is not a member of
'dolfin'
> 
> 
> Haven't gotten around the PETSc stuff yet, so la, math, function, form,
etc. don't get very far yet.
> 
> I am still trying to figure out the module architecture of the system. It
appears that the modules logger 
> and settings are reaching into eachother, but that might just be an issue
with MS not interpreting 
> a friend declaration to be a forward declaration. Need to investigate this
some more.
> 
> Also, in general, I have found automake to create a very complex set of
makefiles that are hard to figure out. 
> The sw works like a charm on Linux, and the code is well written, but the
porting to Windows is a bit hard
> when the overall structure of the project depends on Linux only build
processes. Cross platform processes,
> such as bjam/jam, or ant, would make the project easier to maintain in a
cross platform world.
> 
> The MS IDE is pretty powerful and thus can make life a lot easier for
development. Cross platform builds
> are notoriously laborious so that is nothing new, but automake+configure
makes the job even harder.
> I can try to create a bjam build process that would work cross platform if
you guys are interested.
> 
> Anyways, hope this update helps.
> 
> Theo


-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/