Page 2 of 2
Re: What does your Makefile looks like?
Posted: Wed May 09, 2012 11:34 pm
by Solar
klange wrote: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
Re: What does your Makefile looks like?
Posted: Thu May 10, 2012 8:50 am
by klange
Solar wrote: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)
Re: What does your Makefile looks like?
Posted: Thu May 10, 2012 8:59 am
by Solar
OK, I see where you are coming from. Lucky for you if your collaborators could be "made" to use vim, then.
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 9:28 am
by 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)
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 9:45 am
by Solar
bluemoon wrote:(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.
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 12:01 pm
by 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
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 12:59 pm
by AndrewAPrice
jbemmel wrote: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>
:/
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 2:43 pm
by 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!
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 3:12 pm
by 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.
Re: What does your Makefile looks like?
Posted: Fri May 11, 2012 11:57 pm
by Solar
NickJohnson wrote: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.
Re: What does your Makefile looks like?
Posted: Mon May 14, 2012 12:39 pm
by jbemmel
NickJohnson wrote: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...
Re: What does your Makefile looks like?
Posted: Mon May 14, 2012 1:07 pm
by Combuster
jbemmel wrote: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.
Re: What does your Makefile looks like?
Posted: Thu May 24, 2012 9:36 am
by Ameise
My makefile looks a lot like a Visual Studio project file. In fact, I think that it might be one.
Re: What does your Makefile looks like?
Posted: Thu May 24, 2012 10:12 am
by 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.