Not a deal breaker at all. I have setup my GIT area in a windows share and used Ubuntu to mount using CIFS (replacement for Samba?), so I can build them on both sides. Did this just to make sure my changes to the project do not break Linux builds, which I think should be the minimum requirement for any PR made.
By the end of it, I will have ZPROJECT building and running on Windows as well... :-) Thanks for the file names. That makes it much faster to get to a solution to the problem at hand. On Wed, Mar 16, 2016 at 5:45 AM Kevin Sapper <kevinsappe...@gmail.com> wrote: > There are three files responsible for generating the msvc stuff: > > zproject_vs2008.gsl > <https://github.com/zeromq/zproject/blob/master/zproject_vs2008.gsl> > > zproject_vs20xx.gsl > <https://github.com/zeromq/zproject/blob/master/zproject_vs20xx.gsl> > zproject_vs20xx_props.gsl > <https://github.com/zeromq/zproject/blob/master/zproject_vs20xx_props.gsl> > > > The czmq.import.props is generated in zproject_vs20xx.gsl starting from > line 806. > > The code generator we use in zproject is GSL > <https://github.com/imatix/gsl>. And here it gets tricky for windows > users because I don't know how or if GSL can be build on windows. The > easiest way thus would be to run stuff in a Ubuntu VM. I do understand that > this might be a deal breaker as it takes some time to setup the VM. If that > is the case you could start by fixing czmq's import.props and appveyor.yml > and open PRs even though it's generated. I will then make sure the changes > get applied to zproject. In terms of breaking stuff don't be afraid git and > github make it very easy to revert commits if necessary. > > //Kevin > > 2016-03-16 4:03 GMT+01:00 Osiris Pedroso <opedr...@gmail.com>: > >> I guess I need a çrash courae on zproject, what files are the source that >> get generated into what. >> >> Should I start looking at zproject itself? >> For example, what file is the source for that generated >> czmq\builds\msvc\vs2015\czmq.import.props? >> >> I need to understand that before I can proceed. >> >> I will be happy to fix the Windows build and even maintain it in the >> future, but I hate touching stuff and breaking the build for any platform, >> since I know how hard it is to fix it after the fact. >> >> Sent from my iPad. Regularly foiled by autocorrect. But duck it.. >> >> On Mar 15, 2016, at 17:43, Kevin Sapper <kevinsappe...@gmail.com> wrote: >> >> Hi Osiris, >> >> fixing the windows builds especially on appveyor would be great, given >> that there hasn't been a single successful build since they were >> introduced. There are a lot of contributors that know there way around >> Linux and in various iterations build very solid buildfiles e.g. for >> autotools and cmake. The same cannot be said for windows. In that regard >> the knowledge is spread very thin. Thus it would be great if you could >> share your findings by opening issues or PRs in the corresponding projects. >> Any problems that you can bring forward are welcome, if you can deliver the >> solution as well even better :) >> >> Thanks! >> >> //Kevin >> >> On Di, Mär 15, 2016 at 11:53 , Osiris Pedroso <opedr...@gmail.com> wrote: >> >> I have some 20+ years of Windows development under my belt... still a >> newbie to the zeromq project and to open source volunteering in general >> though, so take my comments with a grain of salt. >> >> I have been fighting the same battle the last month or so. >> >> In the process I have updated some of the documentation to add Windows >> build steps, since they were outdated/incorrect. >> One thing that I noticed in several of the projects, is that you can run >> "CMAKE.exe ." in the main directory and get a solution created that you can >> use to build all tests and the core library as well. The SLN files that are >> checked in are only for the core library. This is not documented anywhere >> that I have seen yet. Found by inspection. >> >> This and the resistance to hold off on merging pull requests until after >> they at least build correctly for the platforms we have automated builds >> setup ends up making Windows a second class citizen. >> Even though we have automated builds enabled, the Windows build has been >> broken for quite a while. >> >> For example, zeromq/zyre won't link in Windows from source for this >> target: >> 1>------ Rebuild All started: Project: perf_local, Configuration: >> DebugLEXE Win32 ------ >> >> I tracked it down to this line in >> czmq\builds\msvc\vs2015\czmq.import.props: >> <PreprocessorDefinitions Condition="'$(Linkage-czmq)' == 'static' >> Or '*$(Linkage-czmq)' == 'ltcg'">CZMQ_STATIC* >> ;%(PreprocessorDefinitions)</PreprocessorDefinitions> >> The line above tells the solution to use CZMQ_STATIC library for ltcg >> linkage, which should be dynamic, since all symbols are defined with >> __imp_XXX preamble indicating they come from a DLLIMPORT directive in the >> code. >> >> The file says it is generated by zproject and should not be hand edited: >> >> ################################################################################ >> # THIS FILE IS 100% GENERATED BY ZPROJECT; DO NOT EDIT EXCEPT >> EXPERIMENTALLY # >> # Please refer to the README for information about making permanent >> changes. # >> >> ################################################################################ >> By the way, this message would be greatly enhanced if it also listed >> which was the source file being processed when it was generated. By the >> way, what README is it talking about? This project's, zproject's, the one >> in the same directory as this file? >> >> This is the final line in that build for all targets in the Zyre project: >> ========== Build: *18 succeeded*, *48 failed*, 18 up-to-date, 0 skipped >> ========== >> From the error log, they seem to all be related to this one problem above. >> >> Earlier this week I proposed to have a build tagged when they complete >> successfully. Same approach could be used to tag when a build successfully >> runs the automated tests. Both of these would give a good indication on >> where to focus efforts to fix broken builds/code allowing one to at least >> start from a working base for each supported platform. >> The idea reception was lukewarm at best. >> >> >> On Tue, Mar 15, 2016 at 4:31 AM Peter Ritter <ritter....@gmail.com> >> wrote: >> >>> HI Pieter >>> >>> >>> >>My advice would be to build it yourself. >>> >>> Interesting advice. Does this imply anything about future windows >>> support? I'm also trying to support both Windows and Linux with my own >>> project and I have a lot of trouble getting various libraries to run on >>> windows because people just don't support windows as well anymore. I have >>> version 4.0.4 installed but there is no Visual Studio project to build it >>> myself. Is there a 'Build Guide' somewhere? Otherwise it is not clear what >>> compiler settings and macro definitions are required to build this. >>> >>> I'm happy with 4.0.4 for now because it does the job, so I have no >>> immediate need to upgrade, but I would like to get rid of the .DLL and link >>> to a .lib only, because the DLL just gets in the way. >>> >>> Thanks, Peter >>> >>> PS: ZeroMQ was a real life safer for me. Just being able to debug client >>> server applications from within a single executable is awsome and worth its >>> weight in gold. . So thanks for all that! >>> >>> On Mon, Mar 14, 2016 at 5:17 PM, Pieter Hintjens <p...@imatix.com> wrote: >>> >>>> My advice would be to build it yourself. >>>> >>>> On Mon, Mar 14, 2016 at 8:31 AM, Mark Studenka <mstude...@perseus.co> >>>> wrote: >>>> > Hello, >>>> > >>>> > I've noticed that there doesn't seem to be a current 4.1.4 Window >>>> installer >>>> > package available on the website. >>>> > >>>> > I'm attempting to upgrade to the latest stable release. Currently I'm >>>> > building my own packages on the unix based platforms but use the >>>> pre-built >>>> > packages for Windows. Does a package exist and the web pages haven't >>>> been >>>> > updated or do I need to build myself if I'd like a current Windows >>>> package? >>>> > >>>> > Thanks for any help. >>>> > >>>> > -mark >>>> > >>>> > >>>> > _______________________________________________ >>>> > zeromq-dev mailing list >>>> > zeromq-dev@lists.zeromq.org >>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> > >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> zeromq-dev@lists.zeromq.org >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
