A list for the developers of CellML tools

Text archives Help


[cellml-dev] r2073 - in pce/branches/yape: . chrome chrome/content defaults defaults/preferences support


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] r2073 - in pce/branches/yape: . chrome chrome/content defaults defaults/preferences support
  • Date: Sat, 02 Feb 2008 14:25:52 +1300

CellML Automated Notifications wrote:
> Author: agarny
> Date: 2008-02-02 11:56:36 +1300 (Sat, 02 Feb 2008)
> New Revision: 2073
>
> Added:
> pce/branches/yape/Makefile.am.in
> pce/branches/yape/README
> pce/branches/yape/application.ini.in
> pce/branches/yape/ball
> pce/branches/yape/call
> pce/branches/yape/chrome/
> pce/branches/yape/chrome/chrome.manifest.in
> pce/branches/yape/chrome/content/
> pce/branches/yape/chrome/content/$LOWERCASENAME.xul.in
> pce/branches/yape/configure.ac.in
> pce/branches/yape/defaults/
> pce/branches/yape/defaults/preferences/
> pce/branches/yape/defaults/preferences/prefs.js.in
> pce/branches/yape/rall
> pce/branches/yape/run
> pce/branches/yape/support/
> pce/branches/yape/support/constants
> pce/branches/yape/support/functions
> pce/branches/yape/support/substitute
> pce/branches/yape/tarbz2
> Log:
> Initial environment (i.e. nothing relevant yet!)

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

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

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?

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.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page