This is yet another problem caused by the fact compilers have a 'file in, file out' interface. (the other problem is performance of the compilation/linking/packaging process). There's simply no reason why input to a compiler should be a file, and no reason why the result should be one.
The convergence of compilers, build systems and package managers
31–40 of 42 posts
Re: The convergence of compilers, build systems and package managers
#32Earlier quoted context omitted.
Doesn't work with fortran, which I found out to my chagrin just this afternoon.
Why doesn't it work? Ninja should work with any tools that you can run from the command line.
Re: The convergence of compilers, build systems and package managers
#33This is yet another problem caused by the fact compilers have a 'file in, file out' interface. (the other problem is performance of the compilation/linking/packaging process). There's simply no reason why input to a compiler should be a file, and no reason why the result should be one.
Could you be more explicit? What do you want instead of a file?
Also, if you store code, intermediate results, dependencies, ..., in a database (could even be in memory), you can reuse these intermediate results. The dependency graph can guide you to decide what needs to be changed etc.
Re: The convergence of compilers, build systems and package managers
#34There is a problem but you're looking at it the wrong way. What's in the compiler's machine code generation phase that the build system needs to know about? If nothing, then making a monolithic system is only going to make your life miserable. Well-designed compilers are already split into (at least) two subsystems: frontend and backend. Frontend takes the program and spits an AST (very roughly speakign, although the…
> I think AST and semantic-analyzer are going to play an increasing role in a variety of software development activities It would be fantastic if source control systems would work on the AST instead of the plain text files, so many annoying problems could be solved there.
Re: The convergence of compilers, build systems and package managers
#35Earlier quoted context omitted.
> I think AST and semantic-analyzer are going to play an increasing role in a variety of software development activities It would be fantastic if source control systems would work on the AST instead of the plain text files, so many annoying problems could be solved there.
There are simpler and less intrusive ways to solve outside-AST issues (like an automatic reformatting pass before each build or each diff) What you're suggesting raises a bunch of new (non-trivial) issues: - What would you do with code comments? Things like "f(/+old_value+/new_value)". - How to store code before preprocessing (C and C++) ? - How to store files mixing several languages (PHP, HTML, Javascript) ? - How…
Comments are included in the AST, the AST should be reprojectable into canonical plaint text.
> - How to store code before preprocessing (C and C++) ?
This could get tricky, punt. cdata
> - How to store files mixing several languages (PHP, HTML, Javascript) ?
Same file format, different semantics. PHP is a DSL.
My new language manifesto includes having a mandatory publicly defined AST.
Re: The convergence of compilers, build systems and package managers
#36Earlier quoted context omitted.
Could you be more explicit? What do you want instead of a file?
Suppose the IDE has the code in memory, it wants it compiled (or syntax checked, or ...). Currently, it needs to write out a file, then call the compiler, and pick up the result from the file system, and parse the result. Ideal, would be a programmer's API to do this. But a compilation service, with RPC calls would already be a major improvement. Also, if you store code, intermediate results, dependencies, ..., in a…
Re: The convergence of compilers, build systems and package managers
#37Re: The convergence of compilers, build systems and package managers
#38Earlier quoted context omitted.
There are simpler and less intrusive ways to solve outside-AST issues (like an automatic reformatting pass before each build or each diff) What you're suggesting raises a bunch of new (non-trivial) issues: - What would you do with code comments? Things like "f(/+old_value+/new_value)". - How to store code before preprocessing (C and C++) ? - How to store files mixing several languages (PHP, HTML, Javascript) ? - How…
> - What would you do with code comments? Things like "f(/+old_value+/new_value)". Comments are included in the AST, the AST should be reprojectable into canonical plaint text. > - How to store code before preprocessing (C and C++) ? This could get tricky, punt. cdata > - How to store files mixing several languages (PHP, HTML, Javascript) ? Same file format, different semantics. PHP is a DSL. My new language manifest…
Re: The convergence of compilers, build systems and package managers
#39This is a great writeup of what I think is an unfortunate trend. When your compiler, build system and IDE are all tightly coupled, you end up locked into a single language. It's hard to develop pieces of your code in multiple languages and have everything play well together. But for many projects that's a good way to do things. For example, in games programming, you might want to use an offline texture compression to…
> But if you need to do something slightly unusual, like calling a shell script to generate resources, it's horrible. Not quite true. Xcode provides a "Run Script" build phase that lets you enter your shell script right into the IDE. A lot of handy environment variables are also there. You can easily reach your project via $SRCROOT, or modify the resources of the output bundle via "${CONFIGURATION_BUILD_DIR}/${PRODUC…
It'll just run the script every time, rather than doing anything smart with dependencies. Output from the script might or might not be picked up and tracked properly by the IDE. If you accidentally mess something up nothing will detect or prevent that.
(Edit: should add that I haven't given it a proper try in recent Xcode versions. I probably should.)
Re: The convergence of compilers, build systems and package managers
#40Earlier quoted context omitted.
What kinds of problems you talking about.
One really obvious one is merge conflicts in the following pattern: #old_file.py ... def func_before(*params): do_things() def func_after(*params): do_other_things() ... If someone adds a function between func_before and func_after, and their coworker adds a different function also between func_before and func_after, you get a merge conflict because the line-based VCS doesn't know how the new functions should be orde…
Or alternatively, I go in by myself and re-arrange the order of functions in a file to improve the clustering. If the VCS thinks the order of functions is meaningless, it won't recognize the change.