Hi Joan, thanks for the input. That is a good reason not to use Makefiles.
Hi Sebastian, thanks for the response. One thing I stumbled upon was that a production release is created from the code the dev-server creates in the debug folder, but only parts of it. (the compiled css and static assets are taken from dist/debug -- while the js is taken from app/) Transpiled JS code is created next to source code in the same folder - which is then used to create a production release using requirejs in the source dir plus transpiled less from dist/debug and other assets that the dev-server (which serves the dev environment) creates(!). The way how different filetypes are compiled, to which target they are compiled and how output from our debug-server is used for production releases makes it hard to understand and maintain the Gruntfile, especially if you try to compose parts of it. As I already mentioned, it is nearly impossible right now to switch to babel. A brush up would be nice, but it means a rewrite of large parts of the Gruntfile anyway. Sadly that is not the only big issue we have, another issue is that every `npm install` will build a production release on the client in order to provide a standalone Fauxton installation. The way it should work is that an "npm publish" creates a release artifact which gets published to npm and contains everything that is needed already, including the transpiled code for standalone installs. I could go on with other issues that annoy me right now and are quite different to standard build/release processes. Why are the paths on the filesystem for dependencies like a swf file not transparent to the Fauxton app? Instead the app itself knows if it (the app itself) is a bundled release or not and decides at runtime(!) based on this state which dependency it should include from where. This is another workaround to deal with the different locations of static assets in dist/debug (swf, fonts, images and css) and the js-sourcefiles in app/ which are differently used for releases and the debug server. It is important to note that we need this workaround because it is not possible to fix the root cause in a proper timeframe without rewriting large parts of the way releases are built. Regarding grunt, Gulp & friends: this post sums my problems with Grunt&Co up very well: http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ - it just takes 5min to read and I could not have written it better. I already spent multiple hours of work trying to brush up our Gruntfile, and because I keep running into walls with it was the reason why I wrote the initial mail. I go with splitting out small parts of the build process and make them composable, independent of the current task runner. We can use them as standalones on the console or in Grunt, like we do with other tasks already [1]. It just felt a bit odd to reimplement a `$(shell find app/ -name '*.less')` in 9 lines of JavaScript [2] -- that is why I had the idea to use a Makefile, next to the nice fact that builds with make are idempotent. shelljs looks interesting for tasks like finding all less files in a folder, I will try it out and maybe use it. Best, Robert [1] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L390 [2] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L77-L86 On Mon, Oct 26, 2015 at 9:59 PM, Sebastian Rothbucher <sebastianrothbuc...@googlemail.com> wrote: > > Hi, > > if it was me, I'd avoid plain makefiles, too. At least for fauxton. What > about sticking with Grunt? We could still do some work to brush up the > Gruntfile. And with a few tweaks, it's portable, even on Win (in fact: I > found another one this WE). > > Best > Sebastian > > On Tue, Oct 20, 2015 at 6:03 PM, Joan Touzet <woh...@apache.org> wrote: > > > Hi Robert, > > > > I'm presently migrating our one Makefile left in couchdb to a Windows > > NMakefile, which uses a different syntax. > > > > git shell works but has enough problems that I don't want to rely on > > it. Sometimes it's almost as much work to debug a GNU Makefile running > > under cygwin as it is to rewrite the entire Makefile as an NMakefile. > > > > It'd be super swell if you could avoid a GNU Makefile. > > > > -Joan > > > > ----- Original Message ----- > > > From: "Robert Kowalski" <r...@kowalski.gd> > > > To: dev@couchdb.apache.org > > > Sent: Tuesday, October 20, 2015 10:12:17 AM > > > Subject: Fauxton Windows developer question > > > > > > Hey there, > > > > > > I am currently working with our old & grown Gruntfile.js [1] together > > > with > > > the files in tasks/ > > > > > > The gruntfile has grown over the years and it got really hard to make > > > changes to our buildsystem. > > > > > > It also has some weird edge cases, as a release is made from the > > > dist/debug > > > folder, but the debug folder and it's contents is created from the > > > task > > > that spins up the devserver. > > > > > > Anyway... right now I am trying to integrate Babel as react-tools are > > > deprecated. After the update I want to update to React 14 (that's > > > where my > > > current journey began). > > > > > > There are some tasks that would perfectly fit into a Makefile because > > > they > > > don't fit in a one liner as `npm run <task>` [2] (e.g. finding all > > > .less > > > files and feed them into the less compiler). I know that some people > > > are > > > using Windows and I am a super Windows noob. > > > > > > Windows Fauxton developers: > > > > > > Do Makefiles run in your Windows dev environment (e.g. via git shell > > > et. > > > al.) or would a make based build for Fauxton exclude you? > > > > > > If it would exclude you, do you have a suggestion what to use? > > > > > > Best, > > > Robert :) > > > > > > > > > [1] > > > https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js > > > [2] > > > https://github.com/apache/couchdb-fauxton/blob/master/package.json#L50 > > > > >