hi,
do you have any suggestions for a better fix for d99b820bd5312b8dbd7d15ceddc4f0d4052d37bb to allow to specify include_prefix as an argument to make?
i accept the issue with ?= being a gnu thing, but i don't yet understand what problems the other changes cause.
include_prefix = vars->include_prefix||combine_path(prefix,"include","pike"); should not change if include_prefix is not specified.
if vars->include_prefix has a value but no include_prefix argument was given, then something else must be wrong.
for include_prefix="$(include_prefix)" $(INSTALLARGS) if include_prefix is not specified as a make argument, this change should not do anything because arguments are checked in install.pike with foreach(argv[1..], string foo) if(sscanf(foo,"%s=%s",string var, string value)==2) vars[var]=value;
greetings, martin.
I'm starting to add some more stuff to the GTK2 module. What should I be using for version control? What is the preferred method? I'm still using the cvs account that was set up for me before. Is that fine, or should I be using hg, git, svn, or something else?
/lsd
You should use CVS for now. The future is likely to be git, but we are not quite there yet.
And 7.8 is stable, so take extreme care to not break it. If you want to experiment keep it in your personal repository for now.
well, since cvs is only for stable 7.8, and the svn repo for 7.9 has not been opened yet, i guess git is the remaining choice. there is a pikex repo which is open for any pike branch. (how does one get access to that? my access is not working, even though it should)
greetings, martin.
I do my work on the branch mast/sneak-7.9 in the pikex git repo (read only git://pike-git.lysator.liu.se/pikex, pushable git-pike@pike-git.lysator.liu.se:pikex). Others are welcome to add to it too, but note that it's a rebasing branch until the official fork. (The only reason for the "mast/" prefix is to allow it to be rebased. If I'm not mistaken it does not imply I'm the only one who can push to it.)
On Mon, Jun 01, 2009 at 09:25:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
(The only reason for the "mast/" prefix is to allow it to be rebased. If I'm not mistaken it does not imply I'm the only one who can push to it.)
it's just a path/label. but either way pushing to a branch that is being rebased is a really bad idea. better to keep a few seperate branches for each committer and 'merge' by rebasing other branches on top of yours as needed.
On Mon, Jun 01, 2009 at 09:25:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
(The only reason for the "mast/" prefix is to allow it to be rebased. If I'm not mistaken it does not imply I'm the only one who can push to it.)
it's just a path/label.
Well, as srb has configured it, the prefix part is necessary to be able to rebase.
but either way pushing to a branch that is being rebased is a really bad idea. better to keep a few seperate branches for each committer and 'merge' by rebasing other branches on top of yours as needed.
Why is that?
On Tue, Jun 02, 2009 at 09:50:05PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Well, as srb has configured it, the prefix part is necessary to be able to rebase.
not sure what he set up, but i guess it is something that specifically allows pushing the rebased branch without a warning. (allow non-fast-forward)
but either way pushing to a branch that is being rebased is a really bad idea. better to keep a few seperate branches for each committer and 'merge' by rebasing other branches on top of yours as needed.
Why is that?
because if i fetch the branch now, then make a change, then you rebase and push your change, and then i push my change after you rebased i'd be effectively undoing your last rebase. i think this can get confusing quickly.
with normal branches this is not a problem because we'd just merge the results...
greetings, martin.
I see. But if you pull before you push, the race window will be small. In a normal non-rebasing branch you'd have to do that anyway, so afaics the only difference from that case is that git won't be able to detect the race.
Sure, it's not ideal, but it's not incredibly bad either.
On Mon, Jun 01, 2009 at 08:30:10PM +0000, Peter Bortas @ Pike developers forum wrote:
do you have any suggestions for a better fix for d99b820bd5312b8dbd7d15ceddc4f0d4052d37bb
Looks like git gibberish. Please provide useful link.
sorry, there does not seem to be away to link to a commit in the code librarian. this is the closest i could come up with:
http://pike.ida.liu.se/development/cvs/pike.xml?between=2009-06-01&and=2...
he first two commits on that page...
greetings, martin.
include_prefix = vars->include_prefix||combine_path(prefix,"include","pike"); should not change if include_prefix is not specified.
Yes, but with your change to Makefile.in, include_prefix _would_ be specified. Thus, the value will change, since the value specified will differ from combine_path(prefix,"include","pike") by default.
hmm, you are right, i didn't think sscanf would asign an empty string to the value and lib_prefix uses the same code, but it works for lib_prefix because the makefile specifies: lib_prefix = $(prefix)/lib/pike so there is always a value.
for include it sets: include_prefix = @includedir@ which could be empty.
setting includedir = $(prefix)/include/pike might do the trick.
greetings, martin.
but what is the use of --includedir if the value is ignored in install.pike?
greetings, martin.
--includedir is a standard autoconf feature, and added to the configure script regardless of wheteher it is used by the specific project or not.
is there any reason not to use it?
vars->include_prefix is referenced twice in install.pike. currently that reference will always be false
if includedir has the wrong value then we could just ignore it and set include_prefix = $(prefix)/include/pike which should be overridable just like lib_prefix
greetings, martin.
is there any reason not to use it?
I'm not sure if there was some specific reason not to use it initally, or if it even _was_ used initially, and then removed for some specific reason. However, one potentially complicating factor for using it is the trailing "pike" in the current default. If you specify an --includedir explicitly, would you still want "/pike" to be appended? (If yes, then it seems rather straightforward to use it actually.)
if includedir has the wrong value then we could just ignore it and set include_prefix = $(prefix)/include/pike which should be overridable just like lib_prefix
True; since the current $(include_prefix) isn't used, there is no particular need to keep the old assignment.
On Tue, Jun 02, 2009 at 10:30:02AM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I'm not sure if there was some specific reason not to use it initally, or if it even _was_ used initially, and then removed for some specific reason. However, one potentially complicating factor for using it is the trailing "pike" in the current default. If you specify an --includedir explicitly, would you still want "/pike" to be appended?
no, the layout i want to create is $prefix/include/pike/version and $prefix/lib/pike/version
setting include_prefix = $(prefix)/include/pike would mean the default is moved from being set in install.pike to being set in src/Makefile.
--new-style should be unaffected by it, except that install.pike in line 2110 is: include_prefix=vars->include_prefix||combine_path(prefix,"include","pike"); which is rather odd. i guess this should be removed. (vars->include_prefix currently is always false anyways)
greetings, martin.
setting include_prefix = $(prefix)/include/pike would mean the default is moved from being set in install.pike to being set in src/Makefile.
Yes, but as long as the default is not changed (including cases where you override $(prefix) etc), that in itself is not a problem.
--new-style should be unaffected by it, except that install.pike in line 2110 is: include_prefix=vars->include_prefix||combine_path(prefix,"include","pike"); which is rather odd. i guess this should be removed.
Why should it be removed? I don't see any particular gain with breaking command line compatibility with previous versions of install.pike, even if that compatibility is not needed by the Makefile.
(vars->include_prefix currently is always false anyways)
When called from the Makefile, yes. You could run it manually.
Yes. I was thinking about mentioning the old W*ndows installer, which ran install.pike with different arguments, but as you say the same actually goes for regular bin_exports as well.
On Tue, Jun 02, 2009 at 11:10:02AM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
--new-style should be unaffected by it, except that install.pike in line 2110 is: include_prefix=vars->include_prefix||combine_path(prefix,"include","pike"); which is rather odd. i guess this should be removed.
Why should it be removed? I don't see any particular gain with breaking command line compatibility with previous versions of install.pike, even if that compatibility is not needed by the Makefile.
ah, right, i didn't consider other uses. it still seems odd that in case of --new-style only include_prefix can be set, but others like lib_prefix are ignored.
i'll commit a patch setting include_prefix=$(prefix)/include/pike and passing it to install.pike in src/Makefile.in.
that should be enough to get rid of the custom patch debian and foresight and probably others are using.
in the end one of the goals is to have all linux packages built without any custom patches at all so that everyone gets the benefit of having pike build with original sources and pike developers are not left to guess what kind of unchecked changes packagers are making.
greetings, martin.
it still seems odd that in case of --new-style only include_prefix can be set, but others like lib_prefix are ignored.
Well, the whole idea of --new-style is to collect everything under a common prefix, so maybe it's not so odd after all.
i'll commit a patch setting include_prefix=$(prefix)/include/pike and passing it to install.pike in src/Makefile.in.
Hm, I just realized a complication with this. While it is true that the default value in install.pike is always combine_path(prefix,"include","pike"), the value of the "prefix" is not necessarily the same as $(prefix). In the case of a --new-style install (which is default), the prefix is modified by the code before include_prefix is computed. So hardcoding it in the Makefile using the make variable $(prefix) would not give the same result. :-/
On Tue, Jun 02, 2009 at 01:50:03PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
it still seems odd that in case of --new-style only include_prefix can be set, but others like lib_prefix are ignored.
Well, the whole idea of --new-style is to collect everything under a common prefix, so maybe it's not so odd after all.
but that would not be the case if someone sets include_prefix as argument to install.pike, which is the odd part because it makes includes be outside of that common prefix, and exactly because of the problem you notice below:
In the case of a --new-style install (which is default), the prefix is modified by the code before include_prefix is computed. So hardcoding it in the Makefile using the make variable $(prefix) would not give the same result. :-/
that is already the case now if someone uses an include_prefix argument.
is there any case where someone tries to set include_prefix with --new-style now?
i'd suggest that we make --new-style work without any arguments and use --traditional for any cases where a flexible layout is desired. after all, it is even possible to get a new-style layout with --traditional by setting the prefix accordingly, so anyone using --new-style together with include_prefix could just use --traditional and set prefix accordingly.
greetings, martin.
On Tue, Jun 02, 2009 at 05:33:09PM +0200, Martin Baehr wrote:
i'd suggest that we make --new-style work without any arguments and use --traditional for any cases where a flexible layout is desired.
the only alternative that i can think of is to add a check in the Makefile to only pass include_prefix to insyall.pike if --traditional is set. but that seems more hackish and harder to maintain than removing vars->include_prefix handling from --new-style.
which one do you prefer?
greetings, martin.
are there any further comments on this question? if not, i'll go aheas and remove vars->include_prefix handling from --new-style in install.pike
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Lance Dillon -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum