#118920 - tepples - Sun Feb 18, 2007 6:23 am
| In a digression about recompiling parts of a project, HyperHacker wrote: |
| So what you're saying is if each source file is compiled to its own object file, there will never be a need to recompile one source file that hasn't changed just because another has? That makes sense |
Of course it makes sense; it's Make.
| HyperHacker wrote: |
| and I suppose if compiling was taking a long time, I could exploit this by storing somewhere the date and time each file was last compiled, and only recompiling if the last modification date is later than this. |
Make does this:
| In GNU Make home page, the package maintainer wrote: |
| If a target file is newer than all of its dependencies, then it is already up to date, and it does not need to be regenerated. The other target files do need to be updated, but in the right order: each target file must be regenerated before it is used in regenerating other targets. |
| HyperHacker wrote: |
| So far, though, I don't think I've had anything take more than 10 seconds to compile, even with tens of thousands of lines. |
But how big of projects have you tackled? LOCKJAW: The Overdose (TOD) has twelve C source code files, several header files, and four GBFS files. "bkgnds.gbfs" depends on compressed .lz files, which depend on .spl4 (for title screen) and .todbg (for in-game background) files, which depend on .bmp files. "samples.gbfs" depends on .8gbm files, which depend on .wav files. Yes, Make is good for more than calling GCC to turn program source code into object code; it can also call programs to turn PC graphics formats into GBA-native compressed graphics formats. In fact, compatibility with Make is why I prefer command-line graphics conversion programs to those that use only a GUI.
| HyperHacker wrote: |
| I'd end up recompiling them all anyway, because just typing "make" is easier than "make file.c". |
Make automatically looks at all the files and sees what needs to be rcompiled based on modification dates. All you have to do is "make tod.gba" or, if tod.gba is listed as the makefile's primary target file, just "make".
| HyperHacker wrote: |
| Bit off topic? |
I can't split a topic in the middle of a post, so I'll split it as of this post.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119019 - HyperHacker - Mon Feb 19, 2007 3:45 am
Heh, but it's still in Graphics. :-p
I'm too lazy to count the number of lines/graphics/etc right now, but last I checked, both added up to over 10000 lines. My Pok?mon level editor has 840KB of source code and graphics, while my Mario Kart 64 "editor" (with no editing functions yet) has 211K. Both also include various files from a "general-purpose" directory (re-useable code), so the totals would be a bit higher than that. Neither of these are NDS apps, but the compile time shouldn't be a lot different, should it?
I don't mean to sound like I'm arguing against the idea of compiling each file to its own object file and not including them all together into one big lump. I'm just trying to understand what all the benefits are.
_________________
I'm a PSP hacker now, but I still <3 DS.
#119051 - keldon - Mon Feb 19, 2007 11:09 am
#1: compilation time. If you have to compile an entire project everytime you edit one file then your compile time is greatly reduced. Plus when you wish to edit only a graphic file why on earth would you want to compile the entire project? It makes no sense.
#2: kick bad habits from early. When you get into doing larger projects you will not be able to work by including c files and will need to be familiar with using makefiles and including header files. There are a few extra keywords that you will be using in some circumstances. You may also find that you are less encouraged to take up good coding practices that are fine for small projects but don't scale up as the task grows.
#119062 - sgeos - Mon Feb 19, 2007 12:18 pm
You might generate source files from fancy user friendly files. This can be time consuming- more so if it is not automated. You can generate object files from binary files. In both cases, make is your friend.
Include can be made to work, but it will work no better than the standard approach; it may indeed not work nearly as well. Very few experienced programmers would be happy to see the include approach. They probably won't want to work on a project with you. If they don't want to work with you, they won't hire you.
-Brendan
#119084 - tepples - Mon Feb 19, 2007 2:48 pm
| sgeos wrote: |
| You might generate source files from fancy user friendly files. This can be time consuming- more so if it is not automated. You can generate object files from binary files. In both cases, make is your friend. |
Can make be taught to operate a GUI conversion tool? Or should developers be diligent to avoid GUI conversion tools that do not also have a command-line mode and warn the authors of those tools that their work will be avoided for this reason?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119102 - wintermute - Mon Feb 19, 2007 6:01 pm
| tepples wrote: |
Can make be taught to operate a GUI conversion tool?
|
No.
| Quote: |
Or should developers be diligent to avoid GUI conversion tools that do not also have a command-line mode and warn the authors of those tools that their work will be avoided for this reason? |
Yes.
This is probably one of the major reasons why old school programmers nearly always provide command line options in their tools.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#119203 - Miked0801 - Tue Feb 20, 2007 7:40 pm
Old-school? Any program that has to do any real, automated work needs a command line interface. GUIs are nice, but command line gets stuff done.
#119206 - poslundc - Tue Feb 20, 2007 8:01 pm
| Miked0801 wrote: |
| Old-school? Any program that has to do any real, automated work needs a command line interface. GUIs are nice, but command line gets stuff done. |
I might narrow that by saying "command line has an almost universally accessible interface for scripting".
Dan.
#119292 - Miked0801 - Wed Feb 21, 2007 5:12 pm
Fair :)
#119296 - sgeos - Wed Feb 21, 2007 6:06 pm
| tepples wrote: |
| Can make be taught to operate a GUI conversion tool? Or should developers be diligent to avoid GUI conversion tools that do not also have a command-line mode and warn the authors of those tools that their work will be avoided for this reason? |
gd is an easy library to use. You should be able to write your own graphic filters. What do you want to do?
-Brendan