Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

> Is there any particular reason why you are starting the build
> infrastructure from scratch, as opposed to branching off the current
> trunk?

The only reason is that it makes my life simpler. You have to remember that
I have never developed any Mozilla-based application. So, I believe that to
start from the PCEnv trunk would only confuse me rather than help me, not to
mention that I do want to revisit the whole user interface, so again I don't
think that to start from the PCEnv trunk would help me.

> Perhaps so this doesn't cause problems later, we should clarify what you
> intend to advocate happens to this 'branch':

It is indeed a 'branch'. The reason for that is that we (Peter, Randall and
I) agreed that my work should be made available in the repository as early
as possible, and one possible way was to 'branch' PCEnv.

> Do you intend for this branch to be used exclusively for demonstration
> purposes, i.e. the look-and-feel created on your branch is then, when
> everyone is happy with it, is then transferred into the core PCEnv.
>
> Or do you plan to suggest that actual implementation changes, such as
> the re-implementation of the build architecture, be merged into /
> replace the current PCEnv?

Definitely the former case. If there are non-GUI things that end up being
useful then great, but otherwise I am indeed mainly concerned with the GUI
at this stage. After all, you definitely have more experience than I do when
it comes to Mozilla-based development, so I would rather trust your work
when it comes to the build architecture than mine.

> If the former is the case, then I guess any new build system is not
> really my concern. In the latter case, I would have serious concerns
> about the new system, for several reasons:
> 1) As a general principle, starting something that already works from
> scratch requires very good justification. Build systems end up
> developing a lot of collected rules for various reasons, to make them
> work under a diverse set of circumstances, and to recreate all of those
> rules would require a lot of effort, and so to balance this there must
> be a very good reason to start again (something which I don't see).
> 2) The new build system structure seems very different both from what
> Mozilla does, and from what the users of Free / Open Source software
> generally expect.
> 3) If we are starting again, we should consider all the options
> properly - if we want to abandon convention we should at least properly
> consider CMake for example. Creating a new ad hoc system will make
> things like supporting cross-compiling, or adding new platforms,even
> harder than it is now should we ever need to do so.

I guess we don't have a problem then.

Still, I would very much appreciate if you could let me know any shortcoming
of my current 'build' architecture (point# #2 and #3). I did create a few
scripts that make my life easier, but my current underlying 'build'
architecture still relies on the use of tools such as autoconf, automake,
configure and make. I have, however, tried to parameterise everything, so
that I can change the contents of files and filenames themselves if required
(this was based on your [PCEnv trunk]/appSupport/substitute-revision
script). I am also concentrating on Linux at the moment, since I am aware
that building a Mozilla-based application under Windows is much more
involved and I don't want to waste time on that.

Anyway, maybe it is something that we can discuss privately (and maybe
Justing/Randall?) rather than through the CellML tools developers list...

Alan.

---

• [cellml-dev] r2073 - in pce/branches/yape: . chrome chrome/content defaults defaults/preferences support, Andrew Miller, 02/02/2008
  • [cellml-dev] r2073 - in pce/branches/yape: . chrome chrome/content defaults defaults/preferences support, Alan Garny, 02/02/2008

---

Archive powered by MHonArc 2.6.18.