fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Dec 11, 2005 at 08:31:32PM -0500, tomtzigt wrote:

> 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 don't mind using Boost when appropriate.

> I'll do the issue reporting right now.

Thanks.

Make sure to use the latest CVS version of DOLFIN, since some issues
may have been solved since the latest "stable" release.

/Anders


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