[liblouis-liblouisxml] Re: Can't build latest liblouisutdml.dll
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Fri, 20 Jun 2014 03:50:29 -0500
Michael,
I agree. Regenerating sem_names.h is the responsibility of the
developers. There is such a thing as over-automation. More generally, we
are dealing with software which is intended to be cross-platform. It
would be interesting to see how other software packages such as firefox
deal with this.
John
On Fri, Jun 20, 2014 at 08:00:16AM +0100, Michael Whapples wrote:
> Hello,
> Sorry if my reply seemed heavy handed, but let's try and look at
> this logically. Here is my reason for such a view regarding the
> changes.
>
> To automate an action in the build process, in my mind would fall in
> the category of enhancement. It is not a necessary change to make,
> its not adding functionality and certainly not fixing an issue.
>
> Being able to build liblouisutdml is a critical feature and thus
> breaking the build system is a major issue. Yes we have two build
> processes and these must respect each other, the GNU make system
> must not break the VC build and equally the VC build system must not
> break the GNU make system.
>
> My view was that the damage caused was significantly greater than
> the benefit gained by these changes.
>
> If the need for these changes were greater (IE.fix to a critical
> issue) then I may be more inclined to seek to modify the VC build
> system to work with these. However due to the enhancement status of
> these changes I feel the responsibility is more on the person
> providing the changes to ensure it does not break anything, or
> modify both build systems to work with the changes.
>
> This is at least the case for the default branch, if you were to do
> such changes on a separate branch then people would have time to
> look at fixing the VC build system (if interested) whilst users such
> as Vic could still get working code.
>
> This is an issue with having two build systems and also one of those
> build systems being something of no interest to me. I have suggested
> in the past we look at using a build system which could work on all
> platforms (eg. scons or cmake), however this recieved comments
> opposing it. Thus if we are going to stick with two build systems we
> must all respect the other build system and at least not break it,
> if not fixing it when we want to make a more major change.
>
> If you really feel that is something which will cause conflict and
> thus be unworkable, then may be it is time for me to explore the
> other build systems (eg. scons or cmake) and use something where I
> do not rely on others to fix the build process.
>
> May be I am just seeing the grass being greener on the other side,
> but its certainly not looking good here. May be I need to experience
> using one of the other systems before I can fully appreciate the
> benefits and disadvantages of those.
>
> Michael Whapples
> On 19/06/2014 16:19, Christian Egli wrote:
> >
> >On 06/19/2014 04:47 PM, Michael Whapples (Redacted sender
> >mwhapples@xxxxxxx for DMARC) wrote:
> >>I have reverted those breaking changes, try now.
> >
> >Michael I am really ticked off at the way this is handled.
> >
> >Look I'm doing you guys a service by fixing the build system so
> >that all the stuff that needs to be built is automatically built.
> >Now as you point out the vc build is basically a parallel build
> >system to the autotools one and needs fixing every time anything
> >in the build system changes. So if I fix the build system that
> >doesn't mean that I also have to fix the vc build scripts. That is
> >up to the people that love to build with vc. They are free to use
> >the autotools.
> >
> >>VC is the preferred build tool on Windows, so we cannot have GNU
> >>make only solutions. Christian please find a fix or this will
> >>have to be reverted.
> >
> >Maybe I'm having a bad day but this is really rubbing me the wrong
> >way. This is not how you treat contributors. This is not what I
> >call collaboration. Please revert the revert and then we can work
> >together to solve this properly.
> >
> >Thanks
> >Christian
> >
>
> For a description of the software, to download it and links to
> project pages go to http://www.abilitiessoft.com
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
