kicad-developers team mailing list archive
Mailing list archive
Re: Re: New library file format
Wayne Stambaugh <stambaughw@...>
Wed, 11 Nov 2009 16:32:35 -0500
Thunderbird 188.8.131.52 (Windows/20090812)
Dick Hollenbeck wrote:
>> I sorry about the confusion but my only point was how well it is
>> supported on Windows. I was hoping you or someone else on the list knew
>> of an example of where it is being used on Windows and Linux so I could
>> get an idea of how difficult it would be to support in in Windows should
>> we decide to use it. There is no doubt that there is enough developer
>> talent in Kicad to make DBUS work on Windows. I am just trying to get a
>> feel for the effort involved. That information would be helpful in any
>> decision making and planning.
>>> Does it work? I don't know. There is a daemon process that runs in
>>> between all the other apps. If that process and all socket level APIs
>>> that are used in the full unix port can be abstracted at their lowest
>>> levels with some kind of platform agnostic thin library, then the merge
>>> of windows support back into the mainstream DBUS library would be the
>>> way to go. I have seen the posting about doing this merge sitting there
>>> for about 2 years now. It is probably not going to happen unless
>>> somebody pushes for it. That is the ideal direction for the Windows
>>> port IMO, simply get rid of it in favor of the genuine DBUS code base.
>>> On the other hand, the Windows support may already work. Maybe we
>>> should put a feeler out on the windows mailing list.
>>> But like most things in software, where there is a will there is a way.
>>> I fully concur that Windows needs to be supported, so you can assume
>>> that any commitment to DBUS is also a commitment to the Windows fixing
>>> and testing of DBUS.
>>> What I grasp onto most tightly in this discussion, is that DBUS is used
>>> everywhere now in a desktop linux distribution, so that code is very
>>> mature, stable, and well supported. And this leads me to believe that
>>> the best path forward for the Windows support is for it fight its way
>>> back into the main code base, by use of abstraction at the lowest
>>> platform specific layers.
>> Perhaps Kicad will be the project that moves this merge forward.
> At first glance it looks like the Windows code was originally a fork.
> For awhile they tried to maintain patches to the main code base.....
> meaning a merge back in may be more political than technical..
Which is always a more difficult problem to solve.
> I will spend some time looking into it and getting you some answers in
> the next couple of weeks.
Thanks for help. I checked out the windows version of DBUS from
SourceForge and took a look around. Interestingly, they are using CMake
to create the make files to handle both MinGW and Visual Studio. It may
be more Windows friendly than I had anticipated. I will try building in
MinGW over the next few days. I really want to finish up the comment
translation first but I'm getting pretty bored with it at this point.