-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Wednesday, May 19, 2004 3:57
PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] New
generated makefile pattern
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