The "About" of most computer programs have a version number, such as "2.1" where usually the first number is the major release and the second number is the minor release. At times the version number is followed by the build number enclosed in parentheses like "2.1 (456)" and more often than not, the build number is a 4 figure number. So I was wondering, how do programmers keep track of the build number?
For Windows, versioninfo resource updated (by build-system) from hand-made data of with information from used VCS
For software produced on OS X, the build number is typically managed using Apple Generic Versioning. You can read the man page for agvtool to get started.
Here are some basic use cases for agvtool:
$ agvtool what-version
$ agvtool next-version -all
$ agvtool new-version -all 456.7
Here's an article from Dave Dribin about how to use it. It's up to the developers to determine when the number should be incremented. (Examples of when you might increment the build number: for every commit, for a daily build, for a weekly build, for every build that is distributed to testers)
Related
I want to understand how the downloaded application of Cygwin relates to the "heart"/"mind" of my system. Yes, I am as green as the Emerald Isles. So, please spare me. Let me give an explanation of the chain of events and my perception of them ("backstory"), so that the motivation for my question can be understood.
Currently, on Cygwin, I can see that it "sees" QUARKy (my [super]username on this comp]. And currently I can see that it (Cygwin) cannot "see" the files contained therein (So there's a, metaphorically speaking: "cognitive dissonance"; somehow it automatically "knows" of QUARKy." yet, it knows nothing of it!). It looks blank when I do the "ls" command when in that directory.
Now, if my memory serves me-- I could swear last time, the FIRST time, I downloaded Cygwin (I had to do a... whatever the appropriate terminology for a "master reset" for a comp. is) I could go into that directory and I could see all of my files-- just like if how it would look to me if I went about accessing the files more conventionally (Do you say "Through a GUI"?). I don't recall doing anything in particular to enable myself to have these privileges.
So, in part, I wonder if I failed to download a package the second time which I had the first. I am certainly having much trouble with the packages this second time around.
I am also wondering if-- though I could swear I am vividly recalling actual experiences of mine-- I am wrong that I ever had such an ability. Therefore, I wonder what "special thing" needs to be done so that Cygwin can see the files contained in this user directory. And I would please like it explained to me how the added special feature enables this privileged. I do see that it should make sense that, having independently downloaded this environment, it should not "naturally" know anything about my comp. But then, it is further striking, I think, that it should know of "QUARKy" and make it a directory. Though, perhaps I place too much weight on this last feature. Afterall, it is just a name and might natural default to making it a directory. Why stop there though?
See how maddening this is for me?!!!
:-( <---- That's what I look like, from now on.
Please help!
Cygwin is not an isolated environment like for example a virtual machine inside VirtualBox. It works on the same filesystem as other Windows applications. Its files could be accessed through any file manager (e.g: Total Commander), and it can access any other file including your home folder in Windows.
Only one thing makes confusion: cygwin uses UNIX-like paths but Windows uses DOS paths. There is a translation method to convert them vica-versa. cygpath utility can do this translation automatically, but it could be done by head as well. Here is some example:
#############################################
# converting to Windows path format:
#############################################
$ cygpath --windows /
C:\cygwin
$ cygpath --windows /home
C:\cygwin\home
$ cygpath --windows /home/username
C:\cygwin\home\username
$ cygpath --windows /cygdrive/c
C:\
#############################################
# converting to Cygwin (UNIX) path format:
#############################################
$ cygpath --unix 'C:\Users\username'
/cygdrive/c/Users/username
$ cygpath --unix 'C:\Windows'
/cygdrive/c/Windows
$ cygpath --unix 'D:\Games'
/cygdrive/d/Games
I am trying to navigate and understand whoami (and other coreutils) all the way down to the lowest level source code, just as an exercise.
My dive so far:
Where is the actual binary?
which whoami
/usr/bin/whoami
Where is it maintained?
http://www.gnu.org/software/coreutils/coreutils.html
How do I get source?
git clone git://git.sv.gnu.org/coreutils
Where is whoami source code within the repository?
# find . | grep whoami
./man/whoami.x
./man/whoami.1
./src/whoami.c
./src/whoami
./src/whoami.o
./src/.deps/src_libsinglebin_whoami_a-whoami.Po
./src/.deps/whoami.Po
relevant line (84):
uid = geteuid ();
This is approximately where my rabbit hole stops. geteuid() is mentioned in gnulib/lib/euidaccess.c, but not explicitly defined AFAICT. It's also referenced in /usr/local/unistd.h as extern but there's no heavy lifting related to grabbing a uid that I can see.
I got here by mostly grepping for geteuid within known system headers and includes as I'm having trouble backtracing its definition.
Question: How can I dive down further and explore the source code of geteuid()? What is the most efficient way to explore this codebase quickly without grepping around?
I'm on Ubuntu server 15.04 using Vim and some ctags (which hasn't been very helpful for navigating existing system headers). I'm a terrible developer and this is my method of learning, though I can't get through this roadblock.
Normally you should read the documentation for geteuid. You can either read GNU documentation, the specification from the Open Group or consult the man page.
If that doesn't help you could install the debug symbols for the c-library (it's called libc6-dbg or something similar) and download the source code for libc6) then you point out the path to the source file when you step into the library.
In this case I don't think this would take you much further, what probably happens in geteuid is that it simply issues an actual syscall and then it's into kernel space. You cannot debug that (kernel) code in the same way as you would debug a normal program.
So in your case you should better consult the documentation and read it carefully and try to figure out why geteuid doesn't return what you expect. Probably this will lead to you changing your expectation of what geteuid should return to match what's actually returned.
I know I can get the version number of ASDF itself with (asdf:asdf-version). But the same does not work with all other packages I load using ASDF, e.g. (my-system:my-system-version). Is there any programmatic way to get the value of a :version keyword in a system definition?
(defsystem my-system
...
:version "0.1"
...)
I am writing a simple HTTP server and would like to include the version number in the Server HTTP header. Anyway, it is a common need for any program to be able to print out its version number somewhere for user information. Of course, I'd like the version number to be defined only in one place, since I may forget to update it in multiple places.
(slot-value (asdf:find-system 'my-system) 'asdf:version)
How to include SVN revision of my project (not file revision) in C source code or in Makefile?
We use a line like this in our makefile:
REPO_REV := $(shell svnversion -n)
That stores the revision number of the working copy into a make variable. To use it in C code, you can have your makefile use that value to define a macro on the compiler command line (something like -DREPO_REV=$(REPO_REV) for gcc).
From the SVN book:
New users are often confused by how the $Rev$ keyword works. Since the repository has a single, globally increasing revision number, many people assume that it is this number that is reflected by the $Rev$ keyword's value. But $Rev$ expands to show the last revision in which the file changed, not the last revision to which it was updated. Understanding this clears the confusion, but frustration often remains—without the support of a Subversion keyword to do so, how can you automatically get the global revision number into your files?
To do this, you need external processing. Subversion ships with a tool called svnversion, which was designed for just this purpose. It crawls your working copy and generates as output the revision(s) it finds. You can use this program, plus some additional tooling, to embed that revision information into your files. For more information on svnversion, see the section called “svnversion—Subversion Working Copy Version Info” in Chapter 9, Subversion Complete Reference.
I am writing my MSc with LaTeX and I have the problem that sometimes my words are divided in a wrong way.
My language is spanish and I'm using babel package.
How could I solve it?
For example: propuestos appears prop-uestos (uestos in next line). It should be pro-puestos.
Thanks!!
If you only have a small number of hyphenation errors to correct, you can use \hyphenation to fix them. For instance: \hyphenation{pro-puestos}. This command goes after \documentclass and before \begin{document}.
You can put more than one dash in, if you want to give TeX more line-breaking options: \hyphenation{tele-mun-dos}. You can list many words inside the braces; put spaces between them.
If more than a handful of words are wrong, though, TeX is probably using hyphenation patterns for the wrong language -- and if "propuestos" were an English word, it would be hyphenated after "prop", so that's another point in favor of that theory. Do you get a message like this when you run LaTeX?
Package babel Warning: No hyphenation patterns were loaded for
(babel) the language `Spanish'
(babel) I will use the patterns loaded for \language=0 instead.
If so you need to reconfigure your TeX installation with Spanish hyphenation turned on. There should be instructions for that in the manuals that came with the installation. Unfortunately, this is one of the places where TeX's age shows through -- you can't just load a package with the proper hyphenation rules (or Babel would do that); you have to do it when compiling the "base format" with INITEX, which is a maintenance operation. Modern TeX installations have nice utilities for that but they're all different and I don't know which one you're using.