Hi Lorenzo,
> > We're here talking about the make and build systems. > > Which doesn't have much to do with 3rd parties, after all everyone can > > download the binary release pre-built and don't care about it. > > As for hbmk, it's just one tool, and hbmk2 is even compatible. > > Sorry, I don't understand. What I meant is that f.e. xhgtk uses hbcc > and hbcmp commands in the makefiles, if we remove them, it doesn't > build anymore and they'll have to have 1.0.1 makefiles and 1.1 > makefiles since there is no hbmk2 for 1.0.1. Probably those hb* aliases will stay (for a while), with content converted to wrappers to hbmk2. This is the least concern of the whole bunch IMO, it's three files. > > Overall I see no point to limit ourselves to the state of year > > ~2000 with regards to the build/make system and exact > > file compatibility down to the exact names and envvar usage. > > Let's look forward, that's what I'd say, otherwise we never reach > > anywhere. > > We all have preferences in names and standards, what is important for > me is the respect of the community. Changes that affect the users need > to be done only when really necessary and giving the time to test and > adapt. > Other projects have stable branch and development branch, with > backports and bug fixing on the stable and new code in the > development. It's clear we don't have the resources for this schema, > but we can easily use a "add new now and remove old next" one. If you can maintain, document, and test everything in parallel, plus every combinations (and if there aren't any collisions or non-cross compatible changes), this could be ideal. We _are_ running on limited sources though, while investing huge amounts of time in this already, so I'd ask for a little flexbility from users so that we can advance more efficiently. > > What I'd suggest is to gather all changes into one document, > > or even better, _finally_ clearly document the make methods > > and make them simpler, so everyone can easily adapt in > > one pass to the 1.1.x way. I've started this with /INSTALL, > > plus most thing are already in whatsnew.txt > > I would perfectly agree if we were a closed source company that > release binaries with "setup, next, next, end" installation, but since > we're on sourceforge we know that every user can ( and we hope ) > download the svn and build harbour from sources. Also we have to admit > that historically the use of cvs/svn has been the "normal" way to use > Harbour. This means that probably there are many different "local > envs" out there and not all can/want to start from scratch every time. That's true but so far let's admit it, it was a huge PITA to start with Harbour. Not for me, not for you, as we've spent weeks to tune it for our needs, but for "normal" ppl, not reading this list every day, a build is still a pain (despite all efforts). So, in order to make this thing documentable, easy to use - as you say for open source users who wish to make own builds - we need to streamline, for the benefit of the community, and for the benefit of us developers, and with some minor sacrifice from "power users", who can probably adapt to these changes quite easily. Besides minor files laying around which are less important, my two (three) main concerns are: 1) Current parallel make systems: We should dump non-GNU. 2) Current parallel Harbour make tool: We should keep only one. +1) As few "satellite" so called "helper" (which are IMO only helping a few ppl and confusing lots of others) batches/scripts as possible. That's the goal. If we can provide backward compatibility for major issues, and if we can do it without major impact on implementing new stuff, or creating big confusion / additional maintenance nightmare, _we should do it_, but not for any price. Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
