Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25664

Re: Dependency resolution in Java builds

Show all headers | View raw

On Feb 8, 11:06 pm, Markus Gessner <nos...@nospam.com> wrote:
> Hello!
>
> First of all, please excuse my typos of yesterday, it was a bit late
> here in Europe.
>
> On Tue, 8 Feb 2011 17:28:50 -0800 (PST), Joshua Maurice wrote:
> > In short, all commonly available build systems suck. It's just a
> > difference of degree. That includes the idiomatic solution of
> > "Recursive Make Considered Harmful" with gnu make and gcc -M on c++
> > code. Ex: Try removing a cpp file, and see if your link output gets
> > rebuilt. See what happens when you add a new header file which hides
> > another header file on an include search path.
>
> This may happen, but in my everyday work I never came across such
> situations. We even had a medley of metacompilers (moc, proc ...), and
> the handling of the additional dependencies introduced by them also
> always worked. You only had to explicitly add source files to some
> *.pro-files, the makefiles were generated from, but that I happily
> submitted to, everything else just working.
>
> To sum it up -- this setup, devised a lot of years ago and never
> changed, just worked, I almost never noticed it, which unobtrusiveness
> IMHO is the best one can say about a tool. It was just "issue a command
> and sit back".

I think I'll stick with what I said - it's just a difference of
degree. Once in a blue moon, you could have a new header file which
hides another header file on an include search path, and an
incremental build will produce different results than a full clean
build. Also, as I said, (or perhaps meant to say?), the solution
advocated in "Recursive Make Considered Harmful" is still one of the
best solutions publicly available for C and C++.

Moreover, many of the ideas and concepts presented in that paper are
invaluable. It's what kicked off my quest to become a build expert.

I merely feel that the paper doesn't go far enough. I want a build
system so that, given the correctness of the build system executable,
it is impossible to make source code deltas /or build code/ deltas so
that the incremental build will produce different results than a full
clean rebuild. That, I think, is the critical difference between what
I want and all commonly available build systems. A pom.xml, a
makefile, an ant file, etc., are all executable code, written in an
interpreted domain specific language. I want a build language where
it's impossible to code the wrong thing. As this language is
restricted entirely to builds, I think that such a thing is quite
feasible and practicable. I'm working on it on and off in my spare
time.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Dependency resolution in Java builds Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-08 17:28 -0800
  Re: Dependency resolution in Java builds Michal Kleczek <kleku75@gmail.com> - 2011-02-10 14:17 +0000
    Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-10 19:08 -0500
  Re: Dependency resolution in Java builds Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-09 14:59 -0800
  Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-09 08:02 -0500
  Re: Dependency resolution in Java builds Markus Gessner <nospam@nospam.com> - 2011-02-09 08:06 +0100
  Re: Dependency resolution in Java builds Tom Anderson <twic@urchin.earth.li> - 2011-02-09 23:56 +0000
    Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-10 08:09 -0500
  Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-08 22:14 -0500
  Re: Dependency resolution in Java builds Tom Anderson <twic@urchin.earth.li> - 2011-02-09 23:28 +0000

csiph-web