[nanomsg] Re: Release packaging and build systems
- From: mike <mike@xxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 25 Jul 2013 01:13:49 -0700
I just modified a solution file for a simple project last night (CppIEEmbed),
and changed the version identifier in the solution to the version I had. .. or
rather I added the version 7.0 to something supporting 8.0, 9.0, and 10.0. It
worked.
This might work with NanoMSG depending on other complexities, such as requiring
Platform SDK updated include files or libraries. I think it might be a very
viable option to give a solution that can support the max amount of versions,
and then give a VC++ 6 project file for the oldest (most used for static
compiling) version.....
We should also allow the ability to compile a static library, as well as a
DLL... If you like, I would not mind contributing to this of NanoMSG as a
start to getting involved. I have every single virtual machine of Windows
(being a MSDN developer network user) and have enough space to have continuous
VMs specifically for nanomsg alone...
Let me know what you think,
Mike
___________________________
Mike Guidry
mike@xxxxxxxxxxxxxx
Mike Guidry Group Inc.
On Jul 25, 2013, at 12:43 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Hi all,
>
> The question here seems to boil down to how far we are willing to go to
> accomodate Windows nanomsg developers and not force them to learn new and
> unfamiliar toolchains.
>
> COMMENT: Please note that we are not speaking about *users* of nanomsg on
> Windows! They should be OK with binary packages.
>
> A.) The furthest we can possibly go is maintaining MSVC solution files as we
> did with ZeroMQ. The problem here is twofold. First, MSVC solutions are
> managed via GUI :( Second, every version of MSVC has different solution file
> format, so we would have to maintain multiple versions of the solution files.
>
> B.) If that seems excessive we can provide a way to *generate* MSVC solution
> files. That way the Windows developer can learn just the generation part of
> the toolchain and continue with MSVC IDE as normal.
>
> C.) We can be even less forthcoming and drop MSVC support entirely. In such
> case Windows nanomsg developers would have to learn MinGW toolchain. The
> upside would be maintaining just a single build system.
>
> Thoughts anyone?
> Martin
>
> On 24/07/13 14:59, luca barbato wrote:
>> On Wed, Jul 24, 2013 at 2:26 PM, Gonzalo Diethelm
>> <gonzalo.diethelm@xxxxxxxxx> wrote:
>>> If I had to choose between cross-compilation support and Windows support, I
>>> would opt for Windows support. FWIW.
>>
>> The problem is defining what's Windows support.
>>
>> - Providing headers and binaries so msvc users can just drop them in
>> their project and build their programs?
>> - Providing a solution in release 7z so they can build it on msvc?
>> - Providing a way to cross compile to windows as VLC and many other projects
>> do?
>>
>> For my specific usages not having a way to easily cross compile
>> (including the windows target by the mean of mingw-64) would be a
>> problem since what I have in mind with nanomsg would enjoy that (since
>> all the other bits use the same way).
>>
>> For a contributor learning how to use cmake or autotools, if not
>> necessary, it is at least warmly welcome.
>>
>> As you can see both build systems are made to be extremely
>> straightforward, the autotools one is literally 2 files to edit at
>> most, so even keeping both in sync shouldn't be a huge burden.
>>
>> lu
>>
>
>
Other related posts:
