-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Wednesday, May 19, 2004 5:29
PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] New
generated makefile pattern
That is both correct and the winner of the "bad
joke of the day" award.
Sean
Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
"Recoskie, Chris"
<crecoskie@xxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
05/19/2004 05:12 PM
Please
respond to
cdt-dev
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] New generated makefile pattern
|
|
Ah, I think I am understanding a bit
better…
By dependencies you are basically saying the dependencies for
the source files upon the header files. In your dependency calculator
you are not handling the fact that there is a dependency between a .c file and
a .o file, right?
I was thinking strictly of the dependencies between an input
extension and an output extension.
<BAD_JOKE>Dependencies, dependencies everywhere and
n’er and object file to link!</BAD_JOKE>
___________________________________________
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 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