search

ericmckean / traceur-compiler

Automatically exported from code.google.com/p/traceur-compiler
Apache License 2.0
0 stars 0 forks source link

Unify build scripts #142

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
RIght now we have 2 of build like scripts

build + build.js
traceurc + filecompiler.js

build.js is the new hotness but it is currently tightly coupled with building 
bin/traceur.js.

Here are a few things to do:

1. Use --out bin/traceur.js instead of treating the only argument as the outfile
2. Make build/build hand in the files to compile on the command line
3. Move node related files into src/node/
4. Add support for source-maps to build.js
5. Add support for copy originals (source maps are not useful if the originals 
are not found). Maybe a way to have the source map point to the source files 
instead of copying them?
6. Make traceurc use build.js
7. Rename build.js

etc

Original issue reported on code.google.com by arv@google.com on 16 Oct 2012 at 4:07

GoogleCodeExporter commented 9 years ago 
I think it would be helpful to outline your goal. I guess you are aiming for a 
server-side tranpiler? I decided to go with a client side solution (chrome 
extn) so my issues are different. I embed the compiler in the client and 
compile directly into the page.

Original comment by johnjbar...@chromium.org on 16 Oct 2012 at 4:56

GoogleCodeExporter commented 9 years ago 
My goal is to simplify the offline compiler

Original comment by arv@chromium.org on 16 Oct 2012 at 5:42

GoogleCodeExporter commented 9 years ago 
Ok, but the source-map issue depends on how they are being consumed.  The 
compiled output has a URL ref to the source-map which has a URL ref to the 
original source. I guess if the build provides values assuming file:// then 
server can just make sure to keep src and bin on the same parent.

Original comment by johnjbar...@google.com on 16 Oct 2012 at 9:04

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/traceur-compiler/source/detail?r=91e0e5a

This does 1 and 2

Original comment by arv@chromium.org on 22 Oct 2012 at 3:58

GoogleCodeExporter commented 9 years ago 
The current 
make build
is confusing because bin/traceur.js does not depend on the .js source as far as 
I can tell.

Original comment by johnjbar...@chromium.org on 1 Dec 2012 at 4:25

GoogleCodeExporter commented 9 years ago 
The intent was that "make build" would depend on the source files through 
"build/dep.mk". However, build/dep.mk has no dependencies so that make target 
does not know when it is out of date. This leads to issues when we add and 
remove dependencies.

Original comment by arv@chromium.org on 3 Dec 2012 at 3:59

GoogleCodeExporter commented 9 years ago 
Apparently we include new code by importing the transformation into traceur.js. 
So I think make build should just clean always.

Original comment by johnjbar...@chromium.org on 19 Dec 2012 at 10:53

GoogleCodeExporter commented 9 years ago 
I don't think "make build" should always clean. There are cases where you want 
to run "make test" wich depends on build where you do not want to rebuild.

Original comment by arv@chromium.org on 19 Dec 2012 at 10:58

GoogleCodeExporter commented 9 years ago 
3. Move node related files into src/node/

https://code.google.com/p/traceur-compiler/source/detail?r=7fa8ff1

Original comment by arv@google.com on 8 Jan 2013 at 3:59

GoogleCodeExporter commented 9 years ago 
4 was done with in

https://code.google.com/p/traceur-compiler/source/detail?r=93c4ba7b2fd461b437bca
35ca3af4ca7e4b2f9d2

Original comment by arv@chromium.org on 24 Feb 2013 at 11:44

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/traceur-compiler/source/detail?r=9e7a9fc

build.js can now output multiple files. It is slightly different from the old 
filecompiler.js since it does not put all the files into the same Project. I'm 
not sure if this is something we will need to add back later?

Original comment by arv@chromium.org on 25 Feb 2013 at 9:14

GoogleCodeExporter commented 9 years ago 
The only issue I can think of with a new Project for each file is
is that the UniqueIdentifierGenerator and RuntimeInliner aren't
shared. This means that for every file you output:

- you repeat the inlined runtime functions.
- you get a fresh id generator counter.

This is a bug or not depending on whether you plan to compile
separately and then:
  <script src='file1.out.js'></script>
  <script src='file2.out.js'></script>
or
  cat file1.out.js file2.out.js > file.out.js
  node file.out.js

If the files are really never going to run in the same context,
then no problem.

  Incidentally, filecompiler.js has the opposite problem where only
  the first file output gets the inlined runtime functions.

  (The fact that the generated unique ids are "more unique" than
  necessary is obviously not really a problem.)

----

There is no good (general) solution to the build/dep.mk problem.
The work you do to make sure dep.mk is up-to-date is the same work
you do making it. And the whole point of dep.mk is to save work. If
you're constantly adding and removing files, you might as well just
use 'make force' instead.

  Individual dep files don't help, because with the current system,
  generating deps is almost as slow as compiling.

But.

Making the simplification that everything in 'src' except 'src/node'
is a prerequisite of 'bin/traceur.js', here is a method that seems
to work.

  # Remake if any *.js in 'src' or 'source-map' is newer,
  # excluding 'src/node'.
  bin/traceur.js: src/*.js src/*/*/*.js \
    third_party/source-map/lib/source-map/*.js \
    $(filter-out src/node/%, $(wildcard src/*/*.js))

As long as the simplification holds, this seems fine. If things get
more complex, you might as well go back to generating dependencies.

Original comment by usrbi...@yahoo.com on 26 Feb 2013 at 4:22

GoogleCodeExporter commented 9 years ago 
Closing. ./traceur should take care of all of this now. Please open new bugs as 
needed.

Original comment by arv@chromium.org on 11 Mar 2013 at 4:38