[Monetdb-developers] Build date in Mserver startup info
Hi,
Maybe it would be a good idea to include some information about the build date on startup of Mserver, just like other programs do that (Linux uname -a, Python, etc). That way you quickly can see if you have the latest version...
druif:~/> Mserver # Monet Database Server V4.3.17 (Apr 27 2004, 14:27:43) <----- # Copyright (c) 1993-2004, CWI. All rights reserved. # Compiled for i686-pc-linux-gnu/32bit; dynamically linked. # Visit http://monetdb.cwi.nl for further information. monet>
regards
On Tue, Apr 27, 2004 at 03:52:59PM +0200, Arjan Scherpenisse wrote:
Hi,
Maybe it would be a good idea to include some information about the build date on startup of Mserver, just like other programs do that (Linux uname -a, Python, etc). That way you quickly can see if you have the latest version...
probably beter to keep the welcome message clean. We could simply add a build_date variable to the environment bat. Users could then do an environment.find("build_data").print;
Niels
druif:~/> Mserver # Monet Database Server V4.3.17 (Apr 27 2004, 14:27:43) <----- # Copyright (c) 1993-2004, CWI. All rights reserved. # Compiled for i686-pc-linux-gnu/32bit; dynamically linked. # Visit http://monetdb.cwi.nl for further information. monet>
regards
Arjan Scherpenisse
Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On Tue, Apr 27, 2004 at 03:52:59PM +0200, Arjan Scherpenisse wrote:
Hi,
Maybe it would be a good idea to include some information about the build date on startup of Mserver, just like other programs do that (Linux uname -a, Python, etc). That way you quickly can see if you have the latest version...
probably beter to keep the welcome message clean. We could simply add a build_date variable to the environment bat. Users could then do an environment.find("build_data").print;
Niels
good point.
but there is another issue/problem:
obviously, the automatic build date update does only work for code that is indeed recompiled. Hence, unless you recompile everything from scratch or force some place (e.g., the Mserver binary itself) to be recompiled with *any* change in either of gdk (libbat), monet (libmonet), Mserver, each single module, there is IMHO no convenient way to get a "consistent" build date as intended... Moreover, the build date does not say anything about the source code version that was used for the build...
Stefan
druif:~/> Mserver # Monet Database Server V4.3.17 (Apr 27 2004, 14:27:43) <----- # Copyright (c) 1993-2004, CWI. All rights reserved. # Compiled for i686-pc-linux-gnu/32bit; dynamically linked. # Visit http://monetdb.cwi.nl for further information. monet>
regards
Arjan Scherpenisse
Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
--
Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.11, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On Sat, May 01, 2004 at 03:12:49PM +0200, Stefan.Manegold@cwi.nl wrote:
On Tue, Apr 27, 2004 at 03:52:59PM +0200, Arjan Scherpenisse wrote:
Hi,
Maybe it would be a good idea to include some information about the build date on startup of Mserver, just like other programs do that (Linux uname -a, Python, etc). That way you quickly can see if you have the latest version...
probably beter to keep the welcome message clean. We could simply add a build_date variable to the environment bat. Users could then do an environment.find("build_data").print;
Niels
good point.
but there is another issue/problem:
obviously, the automatic build date update does only work for code that is indeed recompiled. Hence, unless you recompile everything from scratch or force some place (e.g., the Mserver binary itself) to be recompiled with *any* change in either of gdk (libbat), monet (libmonet), Mserver, each single module, there is IMHO no convenient way to get a "consistent" build date as intended... Moreover, the build date does not say anything about the source code version that was used for the build...
indeed right thats the real problem. I think other projects also only show the source code version ie a version or a version plus snapshot date. So we also leave it at what we have, maybe generate a date into the version string, we we release snapshots (which we currently don't).
Niels
Stefan
druif:~/> Mserver # Monet Database Server V4.3.17 (Apr 27 2004, 14:27:43) <----- # Copyright (c) 1993-2004, CWI. All rights reserved. # Compiled for i686-pc-linux-gnu/32bit; dynamically linked. # Visit http://monetdb.cwi.nl for further information. monet>
regards
Arjan Scherpenisse
Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
--
Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.11, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
Niels Nes wrote:
indeed right thats the real problem. I think other projects also only show the source code version ie a version or a version plus snapshot date. So we also leave it at what we have, maybe generate a date into the version string, we we release snapshots (which we currently don't).
Can't make be instructed to always compile or evaluate a file? Some python script could perhaps generate a little C file which has one method to return the (hard coded) date. This method might get called from instances who need it. In the worst case the end binary gets relinked I guess?
I might think too simple
agree (once more ;-)
about the snapshots: well, we do build them everynight, but don't release them, yet. It's on my todo list, just like making the nightly built binary versions usable within CWI. The latter hasn't been realized, yet, since I first want to clean-up and simplify the automatic build and the resulting directory structure, which has had the highest priority, yet... I'll think about whether/how to conveniently release the nightly built source-dist snapshots both within CWI and on SF (or the MonetDB website), and about how to make the nightly built binary versions conveniently usable within CWI. Suggestions, comments, ideas are welcome ;-)
Stefan
indeed right thats the real problem. I think other projects also only show the source code version ie a version or a version plus snapshot date. So we also leave it at what we have, maybe generate a date into the version string, we we release snapshots (which we currently don't).
Niels
Can't make be instructed to always compile or evaluate a file? Some python script could perhaps generate a little C file which has one method to return the (hard coded) date. This method might get called from instances who need it. In the worst case the end binary gets relinked I guess?
In priciple, this might be an option, but it will only work if one calles make in the top-level build directory. In case one calles make only in one of the subdirectories (e.g., src/gdk, or src/modules/plain), which is very convenient to speed-up the re-build process, your solution will not work, and hence result in an "inconsisten" build date.
I might think too simple
... or I'm thinking too complicated ... ;-)
Stefan
Stefan.Manegold@cwi.nl wrote:
Can't make be instructed to always compile or evaluate a file? Some python script could perhaps generate a little C file which has one method to return the (hard coded) date. This method might get called from instances who need it. In the worst case the end binary gets relinked I guess?
In priciple, this might be an option, but it will only work if one calles make in the top-level build directory. In case one calles make only in one of the subdirectories (e.g., src/gdk, or src/modules/plain), which is very convenient to speed-up the re-build process, your solution will not work, and hence result in an "inconsisten" build date.
I can live with that... I never build from a subdir. I think it's quite logical as well to require a full build for consistency on the build number/date.
Fabian wrote:
Stefan.Manegold@cwi.nl wrote:
Can't make be instructed to always compile or evaluate a file? Some python script could perhaps generate a little C file which has one method to return the (hard coded) date. This method might get called from instances who need it. In the worst case the end binary gets relinked I guess?
In priciple, this might be an option, but it will only work if one calles make in the top-level build directory. In case one calles make only in one of the subdirectories (e.g., src/gdk, or src/modules/plain), which is very convenient to speed-up the re-build process, your solution will not work, and hence result in an "inconsisten" build date.
I can live with that... I never build from a subdir. I think it's quite logical as well to require a full build for consistency on the build number/date.
I agree too, I mostly compile from the top dir as well. It just would be nice to have access to this "last toplevel-build-date"; I would use it to quickly check whether my automated nightly build has succeeded or not.
I can live with that... I never build from a subdir. I think it's quite logical as well to require a full build for consistency on the build number/date.
I agree too, I mostly compile from the top dir as well. It just would be nice to have access to this "last toplevel-build-date";
do you "only" do a "make" in the top dir, i.e., re-build only that parts that might have been changed by a "cvs update", or do you re-build from scratch? in the first case, the "last toplevel-build-date" would still require a force re-compile of some part...
I might have a look into this, but not today... maybe even not this week, sorry ...
I would use it to quickly check whether my automated nightly build has succeeded or not.
^^^^^^^^^^^^^^^^^^^^^^^^^^ hm, I guess, we need to talk ... ;-)
Stefan
Stefan Manegold wrote:
do you "only" do a "make" in the top dir, i.e., re-build only that parts that might have been changed by a "cvs update", or do you re-build from scratch? in the first case, the "last toplevel-build-date" would still require a force re-compile of some part...
You could let make on every invokation generate a build_date.c file
echo "const char *BUILD_DATE="`date -R`";" > build_date.c
and let the file who needs the build date include it. This way it always gets recompiled.
I would use it to quickly check whether my automated nightly build has succeeded or not.
^^^^^^^^^^^^^^^^^^^^^^^^^^hm, I guess, we need to talk ... ;-)
Well, it's just a makefile which does a cvs update; make clean; ./bootstrap etc, nothing really fancy here :)
Arjan
You could let make on every invokation generate a build_date.c file
echo "const char *BUILD_DATE="`date -R`";" > build_date.c
and let the file who needs the build date include it. This way it always gets recompiled.
I'll think about it ...
to quickly check whether my automated nightly build has succeeded or not.
^^^^^^^^^^^^^^^^^^^^^^^^^^hm, I guess, we need to talk ... ;-)
Well, it's just a makefile which does a cvs update; make clean; ./bootstrap etc, nothing really fancy here :)
well, to see whether you automated nightly build has succeeded, you could of course simply check the output or return status of make ... ;-)
Stefan
participants (4)
-
Arjan Scherpenisse -
Fabian -
Niels Nes -
Stefan.Manegold＠cwi.nl