Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top