From: Tres F. <tre...@gm...> - 2014-03-19 20:14:50
|
Continuing the conversation in a separate thread... Originated from the Qt Designer UI elements discussion... On Wed, Mar 19, 2014 at 3:48 PM, Lukas W. <luk...@gm...> wrote: > Qt Designer has nothing to with any bundled libraries or the OS you're > building on. Right, and this is the part I'm trying to understand so please pardon any mistakes in assumptions here... The MacPorts question comes from researching other QT based projects and their feasibility to run on Mac. For example, if one wants to run Kate on OSX, this is what Google returns: > http://community.kde.org/Mac Qt is cross-platform, it supports Mac natively. This was my understanding too. I recently purchased a fully loaded Mac Mini for my business and can offer to start this process, but -- again -- it's the feasibility of this build I was trying to gauge in my previous emails. I don't mind jumping right into it, but I was curious as to the roadblocks I might hit. Any information would be a tremendous help. -Tres |
From: Jonathan A. <eag...@gm...> - 2014-03-20 07:01:54
|
Tres I can help out with that as I have a monster imac with lots of ram and cpu power. I think the biggest issue isnt using mac ports. I think the biggest issue is ensuring the dependencies are met. To be honest I do not understand why for the sake of mac we dont bundle them in the repo. Or have the code say hey connect to this server and download the dependencies form it to a location then where the build will know where they are. Another thing I think would be really nice to see is IDE integration but taht isnt the topic of this discussion. On Wed, Mar 19, 2014 at 9:14 PM, Tres Finocchiaro < tre...@gm...> wrote: > Continuing the conversation in a separate thread... Originated from the Qt > Designer UI elements discussion... > > On Wed, Mar 19, 2014 at 3:48 PM, Lukas W. <luk...@gm...> wrote: > >> Qt Designer has nothing to with any bundled libraries or the OS you're >> building on. > > > Right, and this is the part I'm trying to understand so please pardon any > mistakes in assumptions here... > > The MacPorts question comes from researching other QT based projects and > their feasibility to run on Mac. For example, if one wants to run Kate on > OSX, this is what Google returns: > > http://community.kde.org/Mac > > > Qt is cross-platform, it supports Mac natively. > > This was my understanding too. I recently purchased a fully loaded Mac > Mini for my business and can offer to start this process, but -- again -- > it's the feasibility of this build I was trying to gauge in my previous > emails. I don't mind jumping right into it, but I was curious as to the > roadblocks I might hit. Any information would be a tremendous help. > > -Tres > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > -- Jonathan Aquilina |
From: Tobias D. <tob...@gm...> - 2014-03-20 09:21:01
|
Again, it wouldn't change *anything* even if we would add Qt project files and/or bundle the sources of the about 10-15 external libraries. These libraries all are independent projects which still need to be built for the target platform using their individual and specific build system (some use autotools, some CMake, some a custom configure script, some a Makefile only, ....). Like for any platform, someone needs to take care of building these libraries individually (that's where MacPorts jumps in) for the target platform. On Linux, we can simply install these libraries. If it wouldn't be for my private PPA with cross-compiled MinGW packages, building LMMS for Windows would be a mess too. Once the deps on the target platform are available, building LMMS with CMake is absolutely no problem (you can even generate program bundles using CPack). Toby |
From: Jonathan A. <eag...@gm...> - 2014-03-20 13:05:35
|
The way I have seen libreoffice do this is they have an ftp server that downloads the necessary stuff to ones system before starting compilation. Couldnt we do the same with the dependencies regardless of the platform? On Thu, Mar 20, 2014 at 10:20 AM, Tobias Doerffel <tob...@gm... > wrote: > Again, it wouldn't change *anything* even if we would add Qt project > files and/or bundle the sources of the about 10-15 external libraries. > These libraries all are independent projects which still need to be > built for the target platform using their individual and specific > build system (some use autotools, some CMake, some a custom configure > script, some a Makefile only, ....). Like for any platform, someone > needs to take care of building these libraries individually (that's > where MacPorts jumps in) for the target platform. On Linux, we can > simply install these libraries. If it wouldn't be for my private PPA > with cross-compiled MinGW packages, building LMMS for Windows would be > a mess too. > > Once the deps on the target platform are available, building LMMS with > CMake is absolutely no problem (you can even generate program bundles > using CPack). > > Toby > -- Jonathan Aquilina |
From: Tobias D. <tob...@gm...> - 2014-03-20 13:15:23
|
Sure you can prepare downloads, write a script etc. This still does not solve the issue that you have to take care of building each library individually. So, just write a script which downloads, configures, builds, installs every dependency. Of course we can include this script in our repository. |
From: Jonathan A. <eag...@gm...> - 2014-03-20 13:16:52
|
Wouldnt that be an easier way to go for at least mac and windows? On Thu, Mar 20, 2014 at 2:15 PM, Tobias Doerffel <tob...@gm...>wrote: > Sure you can prepare downloads, write a script etc. This still does > not solve the issue that you have to take care of building each > library individually. So, just write a script which downloads, > configures, builds, installs every dependency. Of course we can > include this script in our repository. > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 13:22:04
|
@Toby, So from your statement, you've already done this for Windows, correct? So the main advantage of MacPorts is that is does the heavy lifting for the source dependencies? From your knowledge does MacPorts need to make changes for these dependencies to compile or could we make what would be the equivalent of a wget on each source package and just extract? Am I over thinking this? What I don't want at the end of this is a KDE decorated Window that's drawn to an X11 screen with a bunch of unnecessary QT deps. I would like to do what you did with the Windows side. That said, you must have a pretty well outlined process for the window side, right? Or did you do the equivalent of a MacPorts for Windows and just grab the DLLs needed to run? I'm sorry for so many questions, I'm just trying to gauge the feasibility of this and the QT5 tutorials make Mac Development seem like a breeze where as the MacPorts tutorials make it look much more daunting... -Tres - Tre...@gm... On Thu, Mar 20, 2014 at 5:20 AM, Tobias Doerffel <tob...@gm...>wrote: > Again, it wouldn't change *anything* even if we would add Qt project > files and/or bundle the sources of the about 10-15 external libraries. > These libraries all are independent projects which still need to be > built for the target platform using their individual and specific > build system (some use autotools, some CMake, some a custom configure > script, some a Makefile only, ....). Like for any platform, someone > needs to take care of building these libraries individually (that's > where MacPorts jumps in) for the target platform. On Linux, we can > simply install these libraries. If it wouldn't be for my private PPA > with cross-compiled MinGW packages, building LMMS for Windows would be > a mess too. > > Once the deps on the target platform are available, building LMMS with > CMake is absolutely no problem (you can even generate program bundles > using CPack). > > Toby > |
From: Jonathan A. <eag...@gm...> - 2014-03-20 13:24:34
|
Tres I have used macports, It compiles said packages for you. One thing with macports is I have used it and I find it hard when I uninstall something to remove the stuff installed by mac ports. My goal is to avoid using mac ports all together and pull the dependencies from an ftp server or the like. On Thu, Mar 20, 2014 at 2:21 PM, Tres Finocchiaro < tre...@gm...> wrote: > @Toby, > > So from your statement, you've already done this for Windows, correct? > > So the main advantage of MacPorts is that is does the heavy lifting for > the source dependencies? From your knowledge does MacPorts need to make > changes for these dependencies to compile or could we make what would be > the equivalent of a wget on each source package and just extract? Am I > over thinking this? > > What I don't want at the end of this is a KDE decorated Window that's > drawn to an X11 screen with a bunch of unnecessary QT deps. I would like > to do what you did with the Windows side. > > That said, you must have a pretty well outlined process for the window > side, right? Or did you do the equivalent of a MacPorts for Windows and > just grab the DLLs needed to run? > > I'm sorry for so many questions, I'm just trying to gauge the feasibility > of this and the QT5 tutorials make Mac Development seem like a breeze where > as the MacPorts tutorials make it look much more daunting... > > > -Tres > > > > - Tre...@gm... > > > On Thu, Mar 20, 2014 at 5:20 AM, Tobias Doerffel < > tob...@gm...> wrote: > >> Again, it wouldn't change *anything* even if we would add Qt project >> files and/or bundle the sources of the about 10-15 external libraries. >> These libraries all are independent projects which still need to be >> built for the target platform using their individual and specific >> build system (some use autotools, some CMake, some a custom configure >> script, some a Makefile only, ....). Like for any platform, someone >> needs to take care of building these libraries individually (that's >> where MacPorts jumps in) for the target platform. On Linux, we can >> simply install these libraries. If it wouldn't be for my private PPA >> with cross-compiled MinGW packages, building LMMS for Windows would be >> a mess too. >> >> Once the deps on the target platform are available, building LMMS with >> CMake is absolutely no problem (you can even generate program bundles >> using CPack). >> >> Toby >> > > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 13:26:48
|
> > My goal is to avoid using mac ports all together and pull the dependencies > from an ftp server or the like > Yeah, I'm hoping we lean in that direction too, but that's what I'm worried about... It may not be as easy as we are describing to cherry-pick what we need. I'm hoping Toby's experience with this on Windows shines some light on the situation. -Tres |
From: Jonathan A. <eag...@gm...> - 2014-03-20 13:33:34
|
Agreed here as well. What I am very curious about is where does Toby pull the source code for the dependencies. I am thinking we can and should be able to use the same LMMS repositories toby uses to pull in the dependencies for windows On Thu, Mar 20, 2014 at 2:26 PM, Tres Finocchiaro < tre...@gm...> wrote: > My goal is to avoid using mac ports all together and pull the dependencies >> from an ftp server or the like >> > > Yeah, I'm hoping we lean in that direction too, but that's what I'm > worried about... It may not be as easy as we are describing to cherry-pick > what we need. I'm hoping Toby's experience with this on Windows shines > some light on the situation. > > -Tres > -- Jonathan Aquilina |
From: Tobias D. <tob...@gm...> - 2014-03-20 17:56:19
|
All I do is download the source tarballs from the official project websites whenever there's an update and put them into a Debian package where according rule and control files describe the cross compilation build and package process. Examples: https://launchpadlibrarian.net/165899765/mingw-x-fluidsynth_1.1.6-3.diff.gz https://launchpadlibrarian.net/165871512/mingw-x-libvorbis_1.3.4-1.diff.gz Note that this procedure works only because we can cross-compile for Windows. If I would build everything natively on Windows, I had to write similiar scripts which extract the source tarballs, configure them, build them and put the resulting binaries in a sensible location and so on. I'm not familiar with OS X at all but maybe you should create packages/bundles for each library (like on Linux: libfluidsynth-1.1.6....deb) so when you want to build LMMS, you have to install all of these bundles so that LMMS can find them. Yes, this *is* lot's of work but you're talking about a proprietary platform which doesn't ship free software/libraries - like Windows. It looks like cross-compiling for OS X would work as well (http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt http://www.sandroid.org/imcross/) but it probably will require even more initial efforts. BTW building with MacPorts doesn't mean it will use a faked X or whatever. As long as Qt is built natively with OS backend, everything should be fine. Of course inside LMMS you will not see the regular OS X button style etc. but the uniform LMMS button style. Toby |
From: Jonathan A. <eag...@gm...> - 2014-03-20 18:06:14
|
Toby sadly Mac doesnt work that way. When it comes to making the installers it lumps everything into the executable if you want to call it that. that is why you just drag the file to the applications folder and that is it for installing. Toby is it possible to set an ftp server up to where we can store the source tarballs for both mac and windows and it pulls them from the server and obviously extract them somewhere in the source tree. Obviously this would need to be scripted or a check added to determine which OS we are on. On Thu, Mar 20, 2014 at 6:56 PM, Tobias Doerffel <tob...@gm...>wrote: > All I do is download the source tarballs from the official project > websites whenever there's an update and put them into a Debian package > where according rule and control files describe the cross compilation > build and package process. Examples: > > https://launchpadlibrarian.net/165899765/mingw-x-fluidsynth_1.1.6-3.diff.gz > https://launchpadlibrarian.net/165871512/mingw-x-libvorbis_1.3.4-1.diff.gz > > Note that this procedure works only because we can cross-compile for > Windows. If I would build everything natively on Windows, I had to > write similiar scripts which extract the source tarballs, configure > them, build them and put the resulting binaries in a sensible location > and so on. I'm not familiar with OS X at all but maybe you should > create packages/bundles for each library (like on Linux: > libfluidsynth-1.1.6....deb) so when you want to build LMMS, you have > to install all of these bundles so that LMMS can find them. Yes, this > *is* lot's of work but you're talking about a proprietary platform > which doesn't ship free software/libraries - like Windows. It looks > like cross-compiling for OS X would work as well > (http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt > http://www.sandroid.org/imcross/) but it probably will require even > more initial efforts. > > BTW building with MacPorts doesn't mean it will use a faked X or > whatever. As long as Qt is built natively with OS backend, everything > should be fine. Of course inside LMMS you will not see the regular OS > X button style etc. but the uniform LMMS button style. > > Toby > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 18:09:12
|
Jonathan, Reminder, I can provide an ftp mirror at any time. -Tres - Tre...@gm... On Thu, Mar 20, 2014 at 2:05 PM, Jonathan Aquilina <eag...@gm...>wrote: > Toby sadly Mac doesnt work that way. > > When it comes to making the installers it lumps everything into the > executable if you want to call it that. that is why you just drag the file > to the applications folder and that is it for installing. > > Toby is it possible to set an ftp server up to where we can store the > source tarballs for both mac and windows and it pulls them from the server > and obviously extract them somewhere in the source tree. Obviously this > would need to be scripted or a check added to determine which OS we are on. > > > On Thu, Mar 20, 2014 at 6:56 PM, Tobias Doerffel < > tob...@gm...> wrote: > >> All I do is download the source tarballs from the official project >> websites whenever there's an update and put them into a Debian package >> where according rule and control files describe the cross compilation >> build and package process. Examples: >> >> >> https://launchpadlibrarian.net/165899765/mingw-x-fluidsynth_1.1.6-3.diff.gz >> https://launchpadlibrarian.net/165871512/mingw-x-libvorbis_1.3.4-1.diff.gz >> >> Note that this procedure works only because we can cross-compile for >> Windows. If I would build everything natively on Windows, I had to >> write similiar scripts which extract the source tarballs, configure >> them, build them and put the resulting binaries in a sensible location >> and so on. I'm not familiar with OS X at all but maybe you should >> create packages/bundles for each library (like on Linux: >> libfluidsynth-1.1.6....deb) so when you want to build LMMS, you have >> to install all of these bundles so that LMMS can find them. Yes, this >> *is* lot's of work but you're talking about a proprietary platform >> which doesn't ship free software/libraries - like Windows. It looks >> like cross-compiling for OS X would work as well >> (http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt >> http://www.sandroid.org/imcross/) but it probably will require even >> more initial efforts. >> >> BTW building with MacPorts doesn't mean it will use a faked X or >> whatever. As long as Qt is built natively with OS backend, everything >> should be fine. Of course inside LMMS you will not see the regular OS >> X button style etc. but the uniform LMMS button style. >> >> Toby >> > > > > -- > Jonathan Aquilina > |
From: Jonathan A. <eag...@gm...> - 2014-03-20 18:13:49
|
I think though tres it woudl be good if toby could maintain this as he would know the versions of libs he woudl want to use and if we shoudl bump them all he has to do is throw them on his server. Tres woudl you be willing to provide nightly builds with your machine? On Thu, Mar 20, 2014 at 7:09 PM, Tres Finocchiaro < tre...@gm...> wrote: > Jonathan, > > Reminder, I can provide an ftp mirror at any time. > > -Tres > > - Tre...@gm... > > > On Thu, Mar 20, 2014 at 2:05 PM, Jonathan Aquilina <eag...@gm... > > wrote: > >> Toby sadly Mac doesnt work that way. >> >> When it comes to making the installers it lumps everything into the >> executable if you want to call it that. that is why you just drag the file >> to the applications folder and that is it for installing. >> >> Toby is it possible to set an ftp server up to where we can store the >> source tarballs for both mac and windows and it pulls them from the server >> and obviously extract them somewhere in the source tree. Obviously this >> would need to be scripted or a check added to determine which OS we are on. >> >> >> On Thu, Mar 20, 2014 at 6:56 PM, Tobias Doerffel < >> tob...@gm...> wrote: >> >>> All I do is download the source tarballs from the official project >>> websites whenever there's an update and put them into a Debian package >>> where according rule and control files describe the cross compilation >>> build and package process. Examples: >>> >>> >>> https://launchpadlibrarian.net/165899765/mingw-x-fluidsynth_1.1.6-3.diff.gz >>> >>> https://launchpadlibrarian.net/165871512/mingw-x-libvorbis_1.3.4-1.diff.gz >>> >>> Note that this procedure works only because we can cross-compile for >>> Windows. If I would build everything natively on Windows, I had to >>> write similiar scripts which extract the source tarballs, configure >>> them, build them and put the resulting binaries in a sensible location >>> and so on. I'm not familiar with OS X at all but maybe you should >>> create packages/bundles for each library (like on Linux: >>> libfluidsynth-1.1.6....deb) so when you want to build LMMS, you have >>> to install all of these bundles so that LMMS can find them. Yes, this >>> *is* lot's of work but you're talking about a proprietary platform >>> which doesn't ship free software/libraries - like Windows. It looks >>> like cross-compiling for OS X would work as well >>> (http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt >>> http://www.sandroid.org/imcross/) but it probably will require even >>> more initial efforts. >>> >>> BTW building with MacPorts doesn't mean it will use a faked X or >>> whatever. As long as Qt is built natively with OS backend, everything >>> should be fine. Of course inside LMMS you will not see the regular OS >>> X button style etc. but the uniform LMMS button style. >>> >>> Toby >>> >> >> >> >> -- >> Jonathan Aquilina >> > > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 18:15:04
|
> > Tres woudl you be willing to provide nightly builds with your machine? > My machine is a hosted VPS service so I cannot easily offer a build environment. Hosting the files is a possibility and we can establish an FTP upload for that if you wish. -Tres |
From: Tobias D. <tob...@gm...> - 2014-03-20 18:15:07
|
I don't see why we need a server for this? What's the problem with writing a script which contains lines like wget http://sourceforge.net/projects/fluidsynth/files/fluidsynth-1.1.6/fluidsynth-1.1.6.tar.bz2 wget http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.25.tar.gz and so on? As said, you can write this script which does all of this automatically. Then we can include it and everything is fine. Please don't make things more complicated than they are. |
From: Tres F. <tre...@gm...> - 2014-03-20 18:15:42
|
On Thu, Mar 20, 2014 at 2:15 PM, Tobias Doerffel <tob...@gm...>wrote: > I don't see why we need a server for this? What's the problem with > writing a script which contains lines like > > wget *...* > +1 |
From: Jonathan A. <eag...@gm...> - 2014-03-20 18:16:54
|
Toby what worries me is the versions. in the sense I might pull a newer version and then we have things go horrendously wrong. I am thinking with a centralized ftp server you have control over the versions of things we use. On Thu, Mar 20, 2014 at 7:15 PM, Tobias Doerffel <tob...@gm...>wrote: > I don't see why we need a server for this? What's the problem with > writing a script which contains lines like > > wget > http://sourceforge.net/projects/fluidsynth/files/fluidsynth-1.1.6/fluidsynth-1.1.6.tar.bz2 > wget http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.25.tar.gz > > and so on? As said, you can write this script which does all of this > automatically. Then we can include it and everything is fine. Please > don't make things more complicated than they are. > -- Jonathan Aquilina |
From: Tobias D. <tob...@gm...> - 2014-03-20 18:18:23
|
The download links always contain version numbers. As long as we do not touch our script, you will always download the same version. Furthermore it's much easier to simply change the version number in the script than managing our hosted tarballs (where you would have to change the script anyways due to changing file names). |
From: Jonathan A. <eag...@gm...> - 2014-03-20 18:19:35
|
Very valid point. Besides the two in the pervious email, what other stuff would we need to download in terms of dependencies? On Thu, Mar 20, 2014 at 7:18 PM, Tobias Doerffel <tob...@gm...>wrote: > The download links always contain version numbers. As long as we do > not touch our script, you will always download the same version. > Furthermore it's much easier to simply change the version number in > the script than managing our hosted tarballs (where you would have to > change the script anyways due to changing file names). > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 18:18:28
|
On Thu, Mar 20, 2014 at 2:16 PM, Jonathan Aquilina <eag...@gm...>wrote: > Toby what worries me is the versions. in the sense I might pull a newer > version and then we have things go horrendously wrong. I am thinking with > a centralized ftp server you have control over the versions of things we > use. > They are versioned. We just coordinate the versions we build with the same verions Toby builds with and we are fine. i.e. Toby sends us a list when he updates his Windows build scripts and we grab the URLs for our next build. -Tres |
From: Jonathan A. <eag...@gm...> - 2014-03-20 18:21:33
|
Ok I am in agreement with you guys :) now to get the list of dependencies :) if possible and I can get things rolling on my macbook tonight :) and maybe have a commit ready to pull soon. Toby what woudl be the best way to have cmake determine the os its on and if these dependencies need to be pulled? On Thu, Mar 20, 2014 at 7:18 PM, Tres Finocchiaro < tre...@gm...> wrote: > On Thu, Mar 20, 2014 at 2:16 PM, Jonathan Aquilina <eag...@gm... > > wrote: > >> Toby what worries me is the versions. in the sense I might pull a newer >> version and then we have things go horrendously wrong. I am thinking with >> a centralized ftp server you have control over the versions of things we >> use. >> > > They are versioned. We just coordinate the versions we build with the > same verions Toby builds with and we are fine. > > i.e. Toby sends us a list when he updates his Windows build scripts and we > grab the URLs for our next build. > > -Tres > -- Jonathan Aquilina |
From: Tres F. <tre...@gm...> - 2014-03-20 18:21:37
|
On Thu, Mar 20, 2014 at 2:18 PM, Tobias Doerffel <tob...@gm...>wrote: > The download links always contain version numbers. As long as we do > not touch our script, you will always download the same version. > Furthermore it's much easier to simply change the version number in > the script than managing our hosted tarballs (where you would have to > change the script anyways due to changing file names). > +1. So Toby, do you have a script you are using for Windows now that might get the source downloaded for us, or is it a bit more complicated? I like the cross-compile option on GNU, but the document's text makes it seem like more of a headache than simply building on OSX. Furthermore, I may be able to host an OSX VM for us to share if it comes to that. My Mac Mini is dedicated to software testing, so it is rarely used. -Tres |
From: Tres F. <tre...@gm...> - 2014-03-20 20:41:38
|
Toby/Jonathan, Can I be granted GitHub wiki authoring capabilities for new pages so that we have a centralized place for OSX build related instructions? (tresf) I want to start at least experimenting with the dependencies script tonight and I want to make sure Jonathan and I aren't duplicating any efforts. Long term I would expect the wiki page to solidify into a proper tutorial, but for now it will give us a baseline for progress in an editable document. I would also expect portions (such as scripts) to be pulled removed and put into a dedicated branch, but I'd rather not make a branch for this until we've dove a bit deeper. I particularly like the wiki formatting options for things like this, which is why I'd prefer this route over the kludgy Google docs, etc. -Tres |
From: Jonathan A. <eag...@gm...> - 2014-03-20 21:02:32
|
If you like we can file any issues I have on the issue tracker on my fork if you like. I think though for you and me google docs is a good way to start at first until we have something that works in terms of building on mac. On Thu, Mar 20, 2014 at 9:41 PM, Tres Finocchiaro < tre...@gm...> wrote: > Toby/Jonathan, > > Can I be granted GitHub wiki authoring capabilities for new pages so that > we have a centralized place for OSX build related instructions? (tresf) > > I want to start at least experimenting with the dependencies script > tonight and I want to make sure Jonathan and I aren't duplicating any > efforts. > > Long term I would expect the wiki page to solidify into a proper tutorial, > but for now it will give us a baseline for progress in an editable > document. > > I would also expect portions (such as scripts) to be pulled removed and > put into a dedicated branch, but I'd rather not make a branch for this > until we've dove a bit deeper. > > I particularly like the wiki formatting options for things like this, > which is why I'd prefer this route over the kludgy Google docs, etc. > > -Tres > -- Jonathan Aquilina |