[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] 3.2 packaging
OK... Doing Scott's suggestions would be great, but my know how in the
PackageMaker system is limited at best, and I believe all of that
would have to be done as a BASH script. Reading it in English was
difficult enough (following all the logic of how things would be put
where and if). So, here is what I will do for TODAY:
Package SC's latest SVN, quarks and sc3-plugins.
These will be installed in /Applications
I will make a README that explains where the quarks and sc3-plugins
We can then work on the rest for a future release. It would be nice,
but I don't have the chops to do it quickly. If someone else DOES have
the chops and can write a BASH script to do all the things Scott noted
today, then I would say go for it. An RC would be a nice time to try
this type of thing out. But if not... let's wait.
I can have a package together to put things in /Applications later
this morning. Do I have write permissions on the sourceforge site to
upload 3.2? Or does Dan have to do this?
On Jan 27, 2008, at 7:37 AM, Click Nilson wrote:
Absolutely agree with Dan on need to get a baseline 3.2 sorted soon
(next 24 hours), ahead of any special installer.
Scott, your suggestions sound like they will need a fuller
discussion. There have been many other changes since 3.1 we need to
get out there officially. 3.2 tag should go in soon. We can then go
into the whole installer thing in more detail, but the priority is to
have a base 3.2 especially so everyone can check code for the book
with a known version.
If there is quick resolution of other issues, we can always include
3.2.2 or whatever on the final DVD, but we'll have to see what gets
resolved within the short timescale!
On 27 Jan 2008, at 14:59, Dan Stowell wrote:
Wait a minute, I don't understand what's being discussed here: are
these changes expected to go into 3.2? It sounds like quite a
significant change and we're already about a week late in fixing the
first release candidate.
If these changes affect the build of SC 3.2 at all then we shouldn't
do them, they've missed the boat. If we're just discussing whether or
not to put quarks into the package downloads, or exactly how to put
together the OSX installer package, then fine.
2008/1/27, Scott Wilson <i@xxxxxxxxxxxxxx>:
On 27 Jan 2008, at 05:39, Click Nilson wrote:
I think we should resolve the status of 3.2 too; at what point will
a simple download be available on sourceforge? When do we tag the
source and when is testing officially over? Afraid I don't know how
to tag the source tree, and how to best motivate you all through a
testing regime ; ) I just know we need to resolve this soon.
On the extensions issue, I would just have the extra directory for
all third party libraries/quarks/extensions in the SC application
folder (and not installed by default), and let the user then place
them where they like; maybe have some quark or quark like
functionality to put symbolic links in the platform specific
extensions as before.
This seems unnecessarily flexible to me (why do I need to put them
anywhere?) and complicates installation and configuration. IIRC,
quarks need write access to their directory, so linking to them in
the applications folder means yet more potential permissions issues.
I'm in favour of moving synthdefs and recordings into the
support directories as well for this reason. It would make more
to have the installer put everything there, and make symlinks to
in the application directory.
. OR, we just offer a package with the extensions in the
SuperCollider_f folder and a README.
So this is the option that seems to require the least future
support and causes least messiness on machines. Particularly for
those who have multiple versions of SC around!
I think some of this really arises from the current state of affairs
and will be much simpler once a few issues are resolved. It seems
- Any extension we include in the distribution should be a quark
(this needs the UGen issue to be sorted, yes?)
- There should be a package so installation can be simple and
automated for new and general users.
- Since quarks are versioned the installer can check this and
overwrite as appropriate.
- The multiple versions issue really comes down to the need to
selectively include extensions at compile time, yes? We need a
mechanism for this.
- People who have the multiple versions issue are likely developers,
and know how to deal with extensions, accounts, etc. manually if
needed. It's more important to make life simple for general and new
users than for us (I say at the risk of re-igniting the great quarks
svn debate of 2007 ;-)
Sc-devel mailing list
Sc-devel mailing list
Sc-devel mailing list
/* Joshua D. Parmenter
“Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively
or passively, consciously or unconsciously, he makes choices in this
regard. He may be conservative or he may subject himself to continual
renewal; or he may strive for a revolutionary, historical or social
palingenesis." - Luigi Nono