[Stk] proposal for stk git repository layout

[Beinan Li]

Late to the party ... As for VS support,
has anyone tried free tools for generating multi-platform makefiles/IDE
solutions such as premake:
http://industriousone.com/premake
?

It can be customized to generate any kind of build scripts. But it may need
work to migrate the current STK build pipeline.

We use it successfully at work.

Beinan


On Mon, Sep 30, 2013 at 9:01 AM, Gary Scavone <gary at ccrma.stanford.edu>wrote:

> Hi Stephen,
>
> Thanks for all your efforts!  Here are a few comments or responses to your
> questions:
>
> - What to do about "Debug" and "Release" folders: I like the idea of
> having the Makefile create these folders as necessary.  That said, attempts
> to build STK from Windows VS projects probably won't work without them.  At
> the same time, the latest versions of VS don't support the v6.0 project
> files I have been distributing (and updating) over the years.  So, the
> question is how much do we want to do for the Windows users and what are
> the best options for them?
>
> - config.sub …: Yes, those files are necessary to run the configure script
> and should be kept.  To minimize clutter in the top-level directory, I put
> them in the "config/" subfolder.
>
> - There have been times when I didn't completely clean my distribution
> before making a release, with the result that there were files included
> that shouldn't have been (for example, .o files in the Debug directory).  I
> think it makes sense to go back to the release tarballs and remove those
> files as we notice them.
>
> - RtAudio and RtMidi: each of these distributions has its own set of
> example program files, as well as some extra stuff that people have
> contributed over time.  For example, the RtAudio distribution includes a
> python wrapper and RtMidi has a VS project to compile it as a library.  I'm
> ok with them being contained in the STK repository (in one way or another)
> but they need their own release tags or branches.  I don't know that much
> about submodules … perhaps that might be the solution.
>
> --gary
>
> On 2013-09-29, at 6:28 PM, Stephen Sinclair <sinclair at music.mcgill.ca>
> wrote:
>
> > Hello all,
> >
> > I have been working on my STK git repo, and I hope it is closer to
> > what might satisfy everyone.
> >
> > The "master" branch is the main development branch.  It includes
> > purely source files such as "configure.ac", ".cpp" and ".h" files,
> > etc.  It does not contain the output of autoconf or doxygen, since
> > these are generated files.
> >
> > The "releases" branch contains branches off of "master" for each
> > release.  In this branch, the generated "configure" and html
> > documentation are included.  For each "tarball" commit under
> > "releases", there is a tag associated.
> >
> > This is illustrated in github's network view:
> > https://github.com/radarsat1/stk/network
> >
> > The upshot is that there is a clear link to the development branch for
> > each release, and meanwhile if one browses to the github "releases"
> > page, which presents a download link for each tag in the repository,
> > one sees each release listed there:
> >
> > https://github.com/radarsat1/stk/releases
> >
> > If someone downloads 4.4.4, for example, they will get a file called
> > "stk-4.4.4.tar.gz", and he/she only needs to type "./configure &&
> > make" to build STK.
> >
> > Meanwhile we can continue development in the "master" branch without
> > interference and history-confusing changes due to autoconf and
> > doxygen, etc.
> >
> > A few decisions had to be made:
> > 1. what to do with the disappearing "Debug" and "Release" folders
> > 2. should "config.sub", "config.guess", and "install.sh" be included?
> > 3. remove any files that shouldn't have been in the release tarballs?
> >
> > 1: I decided to add .placeholder files so that the Debug and Release
> > folders are there just as in the tarball releases.  As of commit
> > 8d2e9d9cf, which patches Makefile.in to create these directories if
> > they don't exist, the .placeholder files are removed.
> >
> > 2. I wanted to remove these as they are part of autoconf/automake and
> > should be available on the developer's system, but in the end I found
> > that even after running "autoconf", the configure script would not run
> > correctly without these files present.  I left them in the repository,
> > but perhaps if we move to automake/libtool in the future it won't be
> > necessary to keep them.
> >
> > 3. Any .o, *~, ._*, .DS_Store, etc.. files were removed before any
> > commit to the repository.  Same for a few Mach-O and ELF executables
> > that were in some release tarballs. (Mainly the projects/* folders)
> >
> > So, still to deal with is how RtAudio and RtMidi should be handled.
> > i.e. as separate projects or what.. I'll leave that for a little
> > later, as it is after midnight now ;)
> >
> > My inclination is to keep them in the same repository as STK but
> > generate different "tags" containing different subsets of the files
> > depending on which software is being released -- this could work
> > great, but has to potential to get a bit confusing -- though nothing
> > that we couldn't make easy with some simple scripting.  The
> > alternative is to have 3 separate repositories.  Then there's the
> > question of using git submodules or not.
> >
> > Steve
> >
> > _______________________________________________
> > Stk mailing list
> > Stk at ccrma.stanford.edu
> > http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20131011/9fce622c/attachment.html