Saving newline just in case your keyboard loose them...
-
@boomzilla said:
Could you expand what you mean by this?
Logically, in Java everything is declared simultaneously; there is no processing order. This means that the compiler works by first determining the graph of entities that need to be compiled and then building all of them. This is different from C (and C++), where compiling foo.c to foo.o doesn't mean that bar.c will also get compiled to bar.o, even if the compiler realizes that that probably needs doing. The result of that is that build systems for Java work in rather different ways to ones for C; everything in the current module (which could mean the whole program) is compiled in one go, instead of each source file being handled separately. Make has a pretty strong unstated assumption that extraneous unlisted target files won't get built except by it. You can force make to do the right thing with Java, but it isn't pretty (IIRC — and it's well over a decade since I did this — you have to use lots of marker files and stuff like that to make the build order construction right); ant is a much better solution as it knows what to do with a directory tree with changes scattered through it.In short: the difference in what is assumed about declaration order means that fundamental assumptions by the build system don't work neatly. Hacking around it is possible, but nasty.
-
@Arnavion said:
@blakeyrat said:
@OldCrow said:
I would add that VS project files are also very readable in a text editor. As part of my work (as well as for a certain open source project) I have to deal with project files and make modifications to them that are easier to do in a text editor than in the VS GUI. Yes, the XML is more verbose than a Makefile or a qmake project file, but it's not "unreadable".And against non-readable project files.
Visual Studio project files are perfectly readable, you just need a copy of Visual Studio installed. Same as any other document type. Open it up and look at the Solution tab. Wham.XML as such should not be exposed to human eyes with anything approaching regularity. One of the best points with makefiles is that it was originally meant to be human-generated and machine interpreted. I find that most generated makefiles are easy to read and understand. Perhaps because they were also used by the build-system's makers to debug their own product.
-
@blakeyrat said:
@OldCrow said:
I never said I was against using IDEs. I'm against people not knowing what happens behind the scenes.
Fair enough, but you can teach someone what a Conestoga wagon is without having them commute to work in one.
@OldCrow said:
And against non-readable project files.
That's just dumb.
Visual Studio project files are perfectly readable, you just need a copy of Visual Studio installed. Same as any other document type. Open it up and look at the Solution tab. Wham.
And then go through all the pages looking for the little differences in thee little text bars. Been there, done that, went to dig in the file by hand next.
@blakeyrat said:
1) Why didn't you just use their compiled version? Was it not a DLL?
2) Why didn't you just ask for their project file, and compile it using that? Why were there even two different projects to compare settings against?
3) What math?The other team's target was Linux on ARM. Ours was Windows CE on x86. And yes, they still developed on Visual Studio. Both products were based on the same cross-platform graphics library, which this library extended.
I compared the settings of their library against the settings of our project, I think. If my memory serves, the underlying reason was a third library which was also shared between the teams and referenced by the problematic library, but had a different name for historical reasons. I think. It was some time ago.
x + y = ? , x = corporate management , y = software development
@blakeyrat said:
Now you're just being pedantic. You also fail. The sentence did not restrict the amount of students in the process. It only stated that half your life as a TA would be spent in searching for bugs in the project file of one student or another.If you didn't use Makefiles, you'd spend half your life trying to figure out one student's code. No commentary here, I'm just repeating what you said as to clarify the idiocy for people who may not have been following closely.
-
-
@PJH said:
Hang on... you supply the whole build system with each package that uses waf? EVERY package duplicates the whole build system? Please tell me I've misunderstood this...
You have not misunderstood. It's not supposed to be a big deal. waf is packaged as a single file. It is *possible* to use a system-installed copy of waf, however it has lead to problems before and it is not the way waf is intended to be used.
Note I'm not advocating the use of waf. I haven't used it myself and I wouldn't because it doesn't work on Windows and thus I don't have a use for it. I mentioned it because I've heard of it and it was relevant to the conversation.
-
@PJH said:
Oh - does that mean you have to install Python 5.3 first before you can use it? What if it conflicts with Python 1.0 on my system which is used by everything else on there (I exaggerate, but I'm sure you get my point.)
@OldCrow said:So you have to build python to build something else. Having seen what a python system depends on, that can take some time when bootstrapping. And then there's the problem that occurs when those other packages try to use waf! It's an infinite sequence of building python to build python!
You're grasping at straws now, OldCrow.
- It is unlikely for a distribution to come without Python installed or be incompatible with a repository version (of that same distro or otherwise). waf doesn't even need Python 3 but only Python 2.
- Even if (1) is false, Python is easy to build. It most certainly doesn't have any dependencies that need waf.
- waf supports cross-compiling. (I am aware how hard it is to get cross-compiling to work.)
@OldCrow said:
XML as such should not be exposed to human eyes with anything approaching regularity. One of the best points with makefiles is that it was originally meant to be human-generated and machine interpreted. I find that most generated makefiles are easy to read and understand. Perhaps because they were also used by the build-system's makers to debug their own product.
I find the rules of writing XML are much more regular than the rules of writing Makefiles. For example, I want to have a build with C optimization disabled. In a Makefile, I would go through the following thought process:
- I'm compiling with a Unix compiler.
- Unix compilers use "-g -O0" to disable optimization and build debug symbols into the binary.
- Go find the CFLAGS and add "-g -O0" to the CFLAGS variable.
AFAICT Qt .pro files would require something similar to this as well.
In a VS project file, I don't care about what compiler is used. I set "<Optimization>" to "Disabled".
-
@Arnavion said:
You're grasping at straws now, OldCrow.
And you have misquoted. That wasn't said by me. Now, I'd understand getting the quotes messed up, but then you replied to me by name to something I never said. Congratulations.
And the XML rules may be more regular, but the symbols and general markup don't make in too readable. Qt project files on the other hand are mostly plain text, with the general exceptions being "+=" sequences to add files to groups. Makefiles generated by Qt tend to have the compiler options on a single line. Makes it easy to verify them. Also every file gets its dependencies listed verbatim for that compilation unit only. So if one was missed, you'll know it.
-
@OldCrow said:
And you have misquoted. That wasn't said by me. Now, I'd understand getting the quotes messed up, but then you replied to me by name to something I never said. Congratulations.
I uhh... I blame Community Server. Yeah. CS is TRWTF!@OldCrow said:
Makefiles generated by Qt tend to have the compiler options on a single line. Makes it easy to verify them.
Yep, as long as all your compilers use the same options. Oh what's that? Every Unix compiler has the same options because the retarded Makefile syntax makes people write options instead of expressing intent, so all current and future compilers basically have no choice but to interpret the same options? Self-fulfilling prophecy right there.
You probably don't care about that one Windows compiler that just so happens to not bend into the strong-arming and use the same options.
It's like the Internet in the 90s, when changing the foreground colors on a web page meant replacing font tags instead of changing a single stylesheet.
-
@Arnavion said:
@OldCrow said:
And you have misquoted. That wasn't said by me. Now, I'd understand getting the quotes messed up, but then you replied to me by name to something I never said. Congratulations.
I uhh... I blame Community Server. Yeah. CS is TRWTF!@OldCrow said:
Makefiles generated by Qt tend to have the compiler options on a single line. Makes it easy to verify them.
Yep, as long as all your compilers use the same options. Oh what's that? Every Unix compiler has the same options because the retarded Makefile syntax makes people write options instead of expressing intent, so all current and future compilers basically have no choice but to interpret the same options? Self-fulfilling prophecy right there.
You probably don't care about that one Windows compiler that just so happens to not bend into the strong-arming and use the same options.
It's like the Internet in the 90s, when changing the foreground colors on a web page meant replacing font tags instead of changing a single stylesheet.
You mean VisualStudio C++ Compiler (or whatever the official name was)? Yeah, I've had a Qt project that used it. Turns out it uses cleartext command-line options just like every other compiler on the planet.
What, you didn't actually check what QMake actually does? Shame on you. I'll give you a hint: you can specify the compiler options any way you want.
Funny thing. Make is not limited to a single compiler and neither are makefiles.
-
@OldCrow said:
You mean VisualStudio C++ Compiler (or whatever the official name was)? Yeah, I've had a Qt project that used it. Turns out it uses cleartext command-line options just like every other compiler on the planet.
What, you didn't actually check what QMake actually does? Shame on you. I'll give you a hint: you can specify the compiler options any way you want.
Funny thing. Make is not limited to a single compiler and neither are makefiles.
???
I see you are incapable of reading, so let me repeat myself. Of course the VC++ compiler uses command line options. What it DOESN'T use is the SAME OPTIONS as Unix compilers. For example, Unix compilers use -L to indicate library directories. The VC++ compiler uses /LIBPATH. Now if you use the qmake macros to specify library directories it's fine because qmake will generate the correct commandline for you. But like the example I gave for disabling optimization, the VC++ compiler does not use "-O0 -g" to mean "Generate an unoptimized binary with debug symbols."
And this is just true of Makefile wrappers like qmake. If you're writing raw Makefiles, then IT'S IMPOSSIBLE TO SUPPORT ALL COMPILERS. Makefiles REQUIRE you to write all your compiler options in the raw command-line argument form, which means you have to write -L in your Makefile. And no matter what you use to process that Makefile to use the VC++ compiler on Windows, the VC++ compiler WILL NOT understand the -L option.
Jesus Christ.
-
@Arnavion said:
@OldCrow said:
...
???
I see you are incapable of reading, so let me repeat myself. Of course the VC++ compiler uses command line options. What it DOESN'T use is the SAME OPTIONS as Unix compilers. For example, Unix compilers use -L to indicate library directories. The VC++ compiler uses /LIBPATH. Now if you use the qmake macros to specify library directories it's fine because qmake will generate the correct commandline for you. But like the example I gave for disabling optimization, the VC++ compiler does not use "-O0 -g" to mean "Generate an unoptimized binary with debug symbols."
And this is just true of Makefile wrappers like qmake. If you're writing raw Makefiles, then IT'S IMPOSSIBLE TO SUPPORT ALL COMPILERS. Makefiles REQUIRE you to write all your compiler options in the raw command-line argument form, which means you have to write -L in your Makefile. And no matter what you use to process that Makefile to use the VC++ compiler on Windows, the VC++ compiler WILL NOT understand the -L option.
Jesus Christ.
And I thought that you'd read my earlier posts. I guess that makes us both look dumb.
Let me recap:
-I never write or edit makefiles by hand these days unless it is for a legacy project. I re-generate makefiles at least once a day, upon starting my work, to make sure the makefiles are not out-of-date.
-I do not recommend anyone to write makefiles by hand, other than as a tool for learning to read them. For that purpose, I recommend writing at least 2 school projects with them.
-I strongly support use of makefiles as a way to direct compilation, due to their explicity. If something doesn't compile, the makefile always tells you why. As a consequence of the points above, I support makefile-generating IDEs and project-managers.
-Makefiles are an excellent way to give exact instructions on how to compile something when handing it e.g. to an automated submission system, due to its versatility. it is also readable, allowing for easy re-creation of a project to another makefile-generator (no surprise there).
-If I have to support more than one platform or compiler, I tell QMake the difference. It will then generate makefiles for either with equal ease.
-
@blakeyrat said:
@dkf said:
None, just as your use of ratios of people in what I was replying to was also not relevant. Which was my relevant point.More than 90% of the world doesn't write software.
Objection, relevance?The more I see of how people code in different communities, the more they seem to be self-organized into little sects that have their own self-reinforcing methodologies and supporting tools. Nearly everyone one interacts with inside such a group also only really with other people in the group, so their world-view tends to be that the techniques used by the group are the right ones, whatever the evidence to the contrary. All of which doesn't prove anything. (Except that people are stupid and shortsighted.) But it does mean that ones own experience does not mean that it is appropriate for other groups; they could be in one of the other local minima where what is being suggested is crazytalk (and actually strongly suboptimal as it doesn't actually lead to a minimum in the effort landscape at all).
In short, your original statement about a majority of developers using MSVC (IIRC; it's a while since I answered) was anecdotal; it's quite possibly true for your experience, but not necessarily true over a wider scope. (MSVC is suboptimal if you're developing for quite a few areas, where other toolchains are the class leaders.)
-
@OldCrow said:
-I strongly support use of makefiles as a way to direct compilation, due to their explicity. If something doesn't compile, the makefile always tells you why.
Because [Error: 2] is ever so helpful...
-
@too_many_usernames said:
@OldCrow said:
-I strongly support use of makefiles as a way to direct compilation, due to their explicity. If something doesn't compile, the makefile always tells you why.
Because [Error: 2] is ever so helpful...
I take it you've never used makefiles or programmed on a computer, then?
