Re: [linuxtools-dev] Rebuilding with Source Modifications

[Joel Dice <joel.dice@xxxxxxxxx>]

On Wed, 23 Dec 2009, Niels Thykier wrote:

> Joel Dice wrote:
> > Hi all,
> >
> > I've been using the instructions on
> > http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build to build
> > Eclipse on a Debian Lenny with good success.  However, I'm having
> > trouble convincing the build to notice changes I've made to the source
> > code after the initial build.  In particular, I've made a trivial change to
> > build/eclipse-R3_5_1-fetched-src/plugins/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/Main.java
> > to make it write a message to System.out, but re-running build.sh
> > appears to do nothing.
> >
> > A peek at the top-level build.xml shows that it relies on several
> > timestamp files to determine which stages of the build are complete.  I
> > tried removing provision.sdk-stamp, which led to more logging from
> > build.sh, but it still didn't recompile any source code AFAICT.
> >
> > I imagine I could do a clean build, but that takes over ten minutes,
> > which is prohibitive to making and testing incremental changes.  I'm
> > hoping there's a better way.  Any ideas?
> >
> > Thanks.
> > _______________________________________________
> > linuxtools-dev mailing list
> > linuxtools-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>
>
> Hi
>
> I was one of the people behind the "timestamp" part. In the past, it
> would blindly remove the whole build directory and restart the build
> from scratch whenever you started the build. The timestamps were added
> to prevent that from blindly happening.
>
> Have a look in build.xml near the beginning - there are all the
> "checkpoint" timestamps that you can delete. You probably want to stay
> clear of unpack, buildId and patch - I am not too sure how well the
> build handles rerunning them without a clean (particularly patch will
> probably choke).
>
> ~Niels

Thanks, Niels.  The closest I've gotten to what I want is with this 
command:

  rm -f provision.sdk-stamp build-stamp p2prep-stamp && ./build.sh

This does cause the source file in question to be rebuilt (along with 
every other source file, apparently, regardless of whether it was 
modified).  However, it does not update 
build/eclipse-R3_5_1-fetched-src/installation/plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar 
at all.  I even tried removing said JAR file, hoping that it would be 
recreated by the build, but that didn't work, and I can't figure out what 
is responsible for creating or updating it.

So here are a few new questions:

 1. Which part of the build is responsible for creating or updating
    org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar?  Or, if
    nobody knows offhand, what can I do to track it down?

 2. Is there some way to convince the build to just recompile the source
    files which have changed?  Looking at a few of the low-level build.xml
    files, I see that the pattern is to create a @dot directory if it
    doesn't already exist and compile the code into there.  If that
    directory already exists (which can happen if you pass -Dnoclean=true
    to the Ant process), it won't do anything - even if one or more of the
    source files has changed.

 3. Am I missing something obvious here regarding file dependencies?
    Almost every piece of software I've encountered using Ant or make has
    made use of a file dependency graph, e.g. .jar files depend on some
    set of .class files, each of which depends on a .java file.  I'm not
    seeing any such thing in the Eclipse build system, and that's why I'm
    having such a hard time getting my head around it.

 4. How do Eclipse developers do iterative development and debugging?  Do
    they have the patience to do a clean build every time they make a
    change or do they have shortcuts to reduce the length of each
    change/rebuild/test cycle?

Sorry if any of this is drifting off topic.  If so, I'll take these 
questions elsewhere.