RE: [cdt-dev] New generated makefile pattern

[Sean Evoy <sevoy@xxxxxxxxxx>]

Chris,
There are two basic extension I am thinking
about; a makefile generator that you can supply in the toolchain, and dependency
calculators that you can supply with a tool. They have to interact to get
the deps right.

For example, the default makefile generator
generates I am writing creates makefiles for Gnu make. It is using a dependency
calculator for c and c++ files that suggests a command that gets placed
in the makefiles. It simply ignores the makefile builder when it asks for
the deps to be calculated at the end of the build. If I add a tool definition
that takes file with extension X and makes a file with extension y, then
I might specify a dep calculator that says "do no dep calculation
for this type of file" and make it part of the tool specification.
Either way, when a new tool gets added that needs deps calculated, it has
to use the makefile because that's the logic of the makefile generator.

Another makefile generator might say
"sod that makefile stuff" and wait until the makefile builder
asks for the deps to be recalculated, then run an external process over
the appropriate files (like makedepend, or some perl script, or). The process
to run (and any additional information) will have to come from the dependency
calculator and the generator will have to do the right ting to bring in
those dependency rules.

Yet another might require the indexer,
and start a Job to get at that information after the build completes. Again,
it will have to generate its makefiles appropriately to incldue those deps.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada

"Recoskie, Chris" <crecoskie@xxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

05/19/2004 02:25 PM

Please respond to
cdt-dev

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] New generated makefile pattern

I’m all for removing the dependency
on the indexer and making things customizable.
 
I am not quite sure what feedback
to give yet other than that.  What you’re generating looks fine for
GNU but it’s unclear what it will generate for other toolchains so I guess
I’ll have to wait and see.
 
I need to be able to specify
in my toolchain that an arbitrary extension A (e.g. .c) will be turned
into an output file with extension B (e.g. .obj) via some tool.  Another
tool might take extension X (.asm) and turn those into B’s (.objs) as
well.  Then another tool will take all of those B files and link them
together into another extension (e.g. .out).  Some or all of my tool
definitions may clash with what one would normally want for a GNU toolchain
(e.g. I want .c files to turn into .obj files, not into .o files) so I
need all of these rules to be generated somehow from the toolchain definition
and not hardcoded.  If I can make all that work with a reasonable
amount of effort, then I’m happy.
 
I will be definitely interested
in having a look at what you’ve got.
 
___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
On Behalf Of Sean Evoy
Sent: Wednesday, May 19, 2004 1:27 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] New generated makefile pattern
 

Guys, 
A heads-up. We have been asked to remove the dependency between the indexer
and the makefile generator. To do that, I have made dependency calculation
something that the toolchain must provide (although the indexer-based option
will still be available). As part of this change, I am also planning on
making the makefile generator something that can be contributed too. For
the Gnu-based toolchain we spec out of the box, I have decided to take
advantage of the pre-processor commands in GCC to calculate dependencies
when a source file is built. The pattern of the makefiles will be as follows.

Top-level file will be similar to the existing makefile (note that the
source macros are gone for now...see my final point). The subdirectories
providing source and the object files are now placed in dedicated makefiles
that are included. If I add Chris' submission back in, they macros will
re-appear there. 
################################################################################
# Automatically-generated file. Do not edit!
################################################################################
ROOT := .. 
-include
$(ROOT)/makefile.init
RM := del 
# All of the sources participating in the build are defined here
-include
sources.mk 
-include
objects.mk 
-include
$(SUBDIRS:%=%/subdir.mk)
-include
$(OBJS:%.o=%.d)
-include
$(ROOT)/makefile.defs
LIBS := 
USER_OBJS :=
all: MingX.exe 
MingX.exe: $(OBJS)
        @echo 'Building target: $@'
        g++ -mwindows -o $@ $(OBJS)
$(USER_OBJS)
$(LIBS)
        @echo 'Finished building: $@'
        @echo
clean: 
        -$(RM)
$(OBJS)
 MingX.exe 
.PHONY: all clean deps 
-include
$(ROOT)/makefile.targets

Each subdirectory will have a makefile that supplies the rules needed to
build the sources there. As part of a successful the build step, a dependency
rule will be generated in a file with the same name as the source file,
but with a '.d' extension. The sharp-eyed amongst you may note that I could
take advantage of GCC's newer -MT and -MF flags to accomplish the same
frmatted output, but these flags are not supported in the 2.95 compilers,
so for the sake of users who have not upgraded, I have done more of the
work. The dep makefiles are all included in the top level makefile. Here's
an example: 
################################################################################
# Automatically-generated file. Do not edit!
################################################################################
# Each subdirectory must supply rules for building sources it contributes
main.o: $(ROOT)/main.cpp
        @echo 'Building file: $<'
        @echo g++ -I"C:\Eclipse30I\eclipse\runtime-workspace\MingX\messenger"
-O0 -g3 -Wall -c -fmessage-length=0 -o $@ $<
        @g++ -I"C:\Eclipse30I\eclipse\runtime-workspace\MingX\messenger"
-O0 -g3 -Wall -c -fmessage-length=0 -o $@ $< && \
        echo -n 'main.d ' > main.d && \
        g++ -M -MG -P -w -I"C:\Eclipse30I\eclipse\runtime-workspace\MingX\messenger"
-O0 -g3 -Wall -c -fmessage-length=0 $< >> main.d
        @echo 'Finished building: $<'
        @echo

I will not include a copy of a dep fragment because there is an enormous
number of system headers that get dragged in. Suffice it to say that so
far, the pattern works as well as the old, index-based scheme, and there
is no annoying wait to build while a project is getting indexed. 

*Note* that not everything is finalized. Chris Recoskie submitted a fix
for the older, macro-based mechanism for tracking the sources to a build.
I am going to take a look at that next and see whether it makes sense to
add it back in as the way to handle non-C/C++ sources and simplify the
subdirectory fragment makefiles. 

Despite the lateness of the hour, what I am looking for is some feedback
on how impacted you will be by these changes and if there is anything I
can do to mitigate this. Please remember that relying on the indexer brings
its own raft of problems, so this is an important fix from my perspective.
If there are no serious problems, I will likely be adding this change in
a couple of phases starting tomorrow.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada