[liblouis-liblouisxml] Re: Can't build latest liblouisutdml.dll
- From: "Michael Whapples" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "mwhapples@xxxxxxx" for DMARC)
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Fri, 20 Jun 2014 08:00:16 +0100
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
Other related posts:
