Ho Onno On 16 January 2011 21:37, Onno Kortmann <[email protected]> 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 _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
