2013/1/6 JonY <jo...@users.sourceforge.net>
> On 1/6/2013 18:54, Kai Tietz wrote:
>
> >>>> I'm thinking (perhaps wrongly) that if I start with the unix configure
> >>>> script, I'll be more likely to get bumped over into unix-style,
> pthreads
> >>>> and posix sockets land, where if I start on the visual studio side, I
> >>>> might be more likely to end up with windows threading and winsock.
> >>>> (Just a hope.)
> >>>
> >>> Ugh, that was painful to read. What part of configure implies pthreads
> >>> and posix sockets? GCC source too has configure, does it make pthread a
> >>> requirement? No.
> >>
> >> Well, think about what you're saying... GCC autotools have a bunch of
> checks
> >> for mingw that make the build use windows specific sources. There's
> bound to
> >> be some Unix specific and windows specific source files in QuickFix. If
> the
> >> autotools wasn't written with that in mind, you're screwed. Autotools
> isn't
> >> a one stop ticket to a full cross-platform build without some
> modification.
> >> Take off your pink glasses, autotools isn't the holy grail. He might
> well
> >> run into the wrong source files (and thus Unix stuff like sockets and
> >> pthreads) being used in the autotools build.
> >>
> >> Ruben
> >
> > Hmm, what in hell has any build-environment to do with venture
> > specific target-files? Any good build-environment provides the ability
> > to the programmer to specify special-case sources, allow
> > cross-compilation configure OOTB, providing features to check and test
> > for runtime-environment features, etc. So in any case you need to
> > port venture's source and build-environment to a specific target
> > manually.
> > So the question is not that much *which* build-environment you shall
> > choose, it is more *what* environment is required for my needs. For
> > example, if I want that my venture can be built on cmd on Windows -
> > maybe even with VC - then I should choose a build-environment
> > supporting that best (like CMake). If I want to built mainly on
> > POSIX-environments, or want the ability of cross-compilation then
> > autotools might be a good choice.
> >
> > Kai
>
> Like Kai says, autotools does not imply any API requirement on the host,
> the same can be said of cmake, jam or whatever. Unfortunately, autotools
> IS the golden standard to compare against, it has the capability to:
>
> 1. Detect compiler capabilities.
> 2. Detect C-library API capabilities.
> 3. Detect installed headers and libraries.
> 4. User configure arguments to modify build behavior.
> 5. Add custom search paths easily.
> 6. Modify compiler flags easily.
> 7. Allow user to specify a compiler other than gcc or whatever platform
> default.
> 8. Abstract way to generate shared libraries.
> 9. Stage and install compiled binaries.
> 10. Support cross compiles by simply specifying the triplet.
>
> All this without the need for the user to modify any files at all. I am
> even using it to drive MSVC. No funny files to edit, no editing obscure
> settings, no custom environment variables.
>
> I am annoyed that most other build system simply assume platform
> attributes without testing them. You end up with stupid things like
> outdated assumptions, "Windows does not have ipv6 support at all,
> absolutely none at all, even if it was released with compatible API and
> supported several years ago". I am also sure you have come to libraries
> that insist that you build on Windows for Windows with no way to compile
> from cross from Linux.
>
To get this thread back on-topic and to prove my point (even with autotools
if you didn't have a platform in mind it probably won't work out of the
box), I tried the quickfix autotools and got (the half-expected):
libtool: compile: x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/m/Development/Source/quickfix/src/C++/test -I../../.. -I..
-I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith
-Wwrite-strings -I/libxml/include/libxml2 -O0 -g -MT DictionaryTestCase.lo
-MD -MP -MF .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp
-DDLL_EXPORT -DPIC -o .libs/DictionaryTestCase.o
In file included from ../Exceptions.h:27:0,
from ../Dictionary.h:31,
from DictionaryTestCase.cpp:28:
../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory
#include <sys/socket.h>
^
compilation terminated.
To Frank: I suggest writing some kind of build script or file from the VC
project files, which have a high chance of having all the Windows stuff set
right. Remember to drop stdafx.h and mind specific defines and such that
would signify the exclusion of the Unix code.
Hope this helps,
Ruben
> It might not be the fastest, but it is the most feature complete,
> portable and flexible build system in common use.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
