Re: [Simulavr-devel] Support for Visual Studio?

[Petr Hluzín]

Ho Onno

On 16 January 2011 21:37, Onno Kortmann <address@hidden> wrote:
> Hi Petr,
>> Adding getopt() implementation.
>> Disabling compilation of vpi.h (it uses some strange types and depends
>> on Verilog or something).
>> Changed some #includes.
>> Altered socket interface.
>> Crippled AvrDevice::Load() since it depends on BDF library.
>> (There might be more. Note to self: search for _MSC_VER macro.)
>
> As long as the linux/unix version is not at all affected and you only check in
> extra build/configuration files for the VS build, I do not see any problems.

It is done by #ifdef, it should not affect non-VS builds in any way.

> But please do not break functionality just to support a VS studio build. Such
> as the ELF loading or the _optional_ Verilog interface (which Thomas spent
> some time to make configure checks for!). You should be able to make all these
> settings in your VS build configuration or by properly adapting some #includes
> (while checking that the changes still compile fine on linux/...), not by
> removing stuff nor commenting it out in the Makefile.am.

All the features of Cygwin/Mingw and Linux builds will remain is they
always were.

> I do not use windows, but AFAIK, the cygwin/mingw build still works, doesn't
> it? So I do not really see the point of a VS build, but if you think it is
> worth it and if it does not break or adversely change anything else - why not?

Well, the IDE is quite good and its debugger is very good. Debugging
is really comfortable. And the port was easy.

> Also, as I do not use windows, I am not able to check whether new code that I
> may write will be compilable with VS. And I suppose the MS libraries/APIs
> differ much more from the linux ones than there is a difference between any 
> bsd
> and linux. So you probably need to make sure from time to time then, that the
> VS build still compiles. But as there are not so many changes lately, this
> should not be a big issue :-)

I do not mind fixing code which accidentally breaks VS builds.

>
> What do the others think?
>
> Ahh, and one last thing: Maybe easier than posting the patch would be to make
> a private branch on the simulavr git repo, named petr-*, such as
> petr-visualstudio, which everyone could have a look at then, before it gets
> merged into HEAD. Git simplifies things here. If you do not feel fine doing
> that, just post the patch.

A conversioning tool should help, however given my bad experience with
TortoiseGit I think I would prefer patches.

-- 
Petr Hluzin