What does your Makefile looks like?

[Solar]

Code: Select all

[...]

# vim:noexpandtab
# vim:tabstop=4
# vim:shiftwidth=4

I'm somewhat opposed to these "editor warts". Instead of having per-file settings - which can get quite confusing and inconsistent - you might want to consider having the appropriate settings in your ~/.vimrc file:

For example, to disable tab expansion in Makefiles:

Code: Select all

autocmd FileType make set noexpandtab

[klange]

I'm somewhat opposed to these "editor warts". Instead of having per-file settings - which can get quite confusing and inconsistent - ...

My kernel source repository has these settings in files to force others to conform, not for my own purposes. My vim config (which is about 500 lines long) is already set up for such things. Before I added the hints, I had numerous occasions on which my collaborators committed code that did not follow the style guidelines because their configs specified different tab widths and expansions (and they were too lazy to fix them).

Personally, I deal with a lot of different source files in a number of different tab formats, and thus my vim config is appropriately set for indentation detection. Having the per-file hints ensures that there is no confusion on how the source file should be viewed.

(And if you think my use of hints is bad, you'll probably also not like my embedded folding points; none of those in my Makefile, though)

[Solar]

OK, I see where you are coming from. Lucky for you if your collaborators could be "made" to use vim, then.

[bluemoon]

I would consider setup a cron job that checkout & reformat the source, and probably generate a nightly build.
(That is a missing feature of SVN that do not properly support hook for code reformatter without dangerous hack)

[Solar]

(That is a missing feature of SVN that do not properly support hook for code reformatter without dangerous hack)

A pre-commit hook serves the purpose for code checking just fine, IMHO. Changing the source someone is committing mid-commit, i.e. checking in something that the developer didn't actually commit, is bad mojo.

[jbemmel]

I use Apache Ant (http://ant.apache.org/) for building my OS. While Ant is designed for Java, it is perfectly able to build C(++) programs. Dependency checking is somewhat harder to setup, but overall build time is fast because I use the following construct in build.xml:

<apply executable="${CXX}" dest="${DIR}" dir="${DIR}" parallel="true" failonerror="true" skipemptyfilesets="true" relative="false">
<arg line="-c -m32 -pipe ${C++.FLAGS} {...more flags here...}"/>
<srcfile/>
<fileset dir="${src.dir}" includes="**/*.cpp"/>
<mapper type="regexp" from="([^/\\]*[/\\])*(.*).cpp" to="\2.o"/> <!-- Flatten directories -->
</apply>

this passes all .cpp to gcc in one invocation. On multicore machines it is possible to parallelize the build futher if needed

[AndrewAPrice]

I use Apache Ant (http://ant.apache.org/) for building my OS. While Ant is designed for Java, it is perfectly able to build C(++) programs. Dependency checking is somewhat harder to setup, but overall build time is fast because I use the following construct in build.xml:

<apply executable="${CXX}" dest="${DIR}" dir="${DIR}" parallel="true" failonerror="true" skipemptyfilesets="true" relative="false">
<arg line="-c -m32 -pipe ${C++.FLAGS} {...more flags here...}"/>
<srcfile/>
<fileset dir="${src.dir}" includes="**/*.cpp"/>
<mapper type="regexp" from="([^/\\]*[/\\])*(.*).cpp" to="\2.o"/> <!-- Flatten directories -->
</apply>

this passes all .cpp to gcc in one invocation. On multicore machines it is possible to parallelize the build futher if needed

XML is nice, but it's so verbose! I was setting up the build environment with Apache Marven the other day, with 100 or so dependencies to add to the project, each one was handwritten:

Code: Select all

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>3.0.4.RELEASE</version>
</dependency>

:/

[bubach]

OT:
yeah it's verbose alright. i remember laughing to myself when all the xml hype appeared. like wtf, whats so different to old classic INI files? nesting would be the only thing i can think of, but seriously, where there even a need for something like xml?

[header]
key=value

could be
[header]
key=value
...[header2]
...key=value2

and voila, same thing. just ridiculous the whole thing imo. i mean ffs, you make up the markup!

[NickJohnson]

I think the point is that XML is a good language for data storage, but shouldn't be considered human-readable/editable. Even makefiles are more clean-looking, and that's saying something. At the very least, it should never be considered a good syntax for implementing domain-specific languages (e.g. Ant, Maven, Android layouts, etc.) All arguments for XML being 'standardized' there are basically moot, since different programs make up their own tag names. If you're too lazy to write a simple parser, you shouldn't be implementing a DSL for anything important.

[Solar]

I think the point is that XML is a good language for data storage, but shouldn't be considered human-readable/editable.

I think you got that one backwards.

[jbemmel]

Even makefiles are more clean-looking, and that's saying something.

While I agree with some of the comments regarding XML, I'd like to see the equivalent Makefile for this build command. There is implicit dependency checking built-in, i.e. if one of the source files changes, only that one gets built. My concern isn't with the syntax of the build tools configuration, but the speed of building my OS - because there's typically many builds to do...

[Combuster]

There is implicit dependency checking built-in, i.e. if one of the source files changes, only that one gets built.

With that low standard of dependency checking and intermediates, doing that is equivalent to the following (yes you said you fed all sources directly to gcc even though your actual scriptlet suggest you missed that idea):

Code: Select all

SRCFILES := $(shell find . -type f -name "\*.c")

output_binary: $(SRCFILES)
    gcc -o $@ $(SRCFILES)

Of course, doing things that way for large projects is an invitation to be stabbed in the face. Berkus' solution is already much better even though its dependency checking is still lacking.

A shame that any ant or maven script I've seen generally needs at least 15 seconds before it realizes it has nothing to do. In practice that means that a clean build of a simple android project takes twice as much time as building all 200kloc in my OS.

At any rate: Makefile for the more professional standards.

[Ameise]

My makefile looks a lot like a Visual Studio project file. In fact, I think that it might be one.

[neon]

Hello,

This is to provide an updated version of what the makefiles look like and how it ties into the new build environment. Here is an example of a component (or project) make file:

Code: Select all

NEPTUNE_OUT = $(NEPTUNE_OUT)/bin
NEPTUNE_INSTALL = $(NEPTUNE_INSTALL)/bin
TARGETNAME = cat.exe
SOURCES = main.c
I386_SOURCES = i386/out.c \
   i386/test.c
I386_ASM_SOURCES = i386/i86.asm
!include $(NEPTUNE_ENV)/makefile.def

Architecture specific C or ASM sources are automatically compiled into the project based on the architecture being built for. The OUT and INSTALL paths instruct NMake the default locations to allow per-project control of where the files are located in the final images. Used with our NBuild software, we can automate the building of a complete source tree this way for different architectures and operating system software in a toolchain-independent way.