Opened 8 years ago

Closed 7 years ago

#15123 closed enhancement (fixed)

Gitify autotools package and make it uptodate on 20140114

Reported by: felixs Owned by:
Priority: major Milestone: sage-6.2
Component: packages: optional Keywords: autotools package git
Cc: jondo Merged in:
Authors: Felix Salfelder, Jeroen Demeyer Reviewers: Jean-Pierre Flori
Report Upstream: N/A Work issues:
Branch: u/jdemeyer/ticket/15123 (Commits, GitHub, GitLab) Commit: f658dd9064212be726441b3356710b51f6c7b44b
Dependencies: Stopgaps:

Status badges

Change History (36)

comment:1 Changed 8 years ago by felixs

  • Type changed from PLEASE CHANGE to enhancement

comment:2 Changed 8 years ago by jondo

  • Cc jondo added

comment:3 Changed 8 years ago by git

  • Commit changed from b1f08def27a1e877c340af13b235cb90c46ea506 to 72c453830846583dbfdf2cae224df776ef38ea26

Branch pushed to git repo; I updated commit sha1. New commits:

[changeset:72c4538]add more autotools executables
[changeset:7cc6067]autotools: spkg (#15123)

comment:4 Changed 8 years ago by felixs

  • Dependencies set to #14804
  • Status changed from new to needs_review

u/felixs/autotools is dark red with "failed to determine common ancestor". That shouldn't be a problen, since no existing files are involved.

comment:5 follow-up: Changed 8 years ago by jdemeyer

What will happen with files like spkg-write-makefile? Will they still be part of the new spkg? They should be, because they are required to update the spkg.

Last edited 8 years ago by jdemeyer (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 8 years ago by felixs

Replying to jdemeyer:

What will happen with files like spkg-write-makefile? Will they still be part of the new spkg? They should be, because they are required to update the spkg.

I didn't remove anything. e.g. spkg-write-makefile is still there and that makes sense. I just added the generated makefile, so I can build the package.

... or I didn't understand your question (sorry then).

comment:7 Changed 7 years ago by jdemeyer

  • Status changed from needs_review to needs_work

Needs to be rebased.

comment:8 Changed 7 years ago by jdemeyer

  • Branch changed from u/felixs/autotools to u/jdemeyer/ticket/15123
  • Created changed from 08/30/13 06:42:33 to 08/30/13 06:42:33
  • Modified changed from 12/29/13 18:16:36 to 12/29/13 18:16:36

comment:9 Changed 7 years ago by jdemeyer

  • Authors changed from Felix Salfelder to Felix Salfelder, Jeroen Demeyer
  • Commit changed from 72c453830846583dbfdf2cae224df776ef38ea26 to a2614be865e097d160f2cbf99e44150ea2098461
  • Dependencies #14804 deleted
  • Description modified (diff)

New commits:

c9c194aMerge remote-tracking branch 'origin/develop' into ticket/15123
a2614beUpdate autotools package to git layout

comment:10 Changed 7 years ago by git

  • Commit changed from a2614be865e097d160f2cbf99e44150ea2098461 to 07100d5d19cfd3128311a6e69e93709027272723

Branch pushed to git repo; I updated commit sha1. New commits:

07100d5Make an empty git repo for autotools installer

comment:11 Changed 7 years ago by jdemeyer

  • Dependencies set to #14804
  • Modified changed from 01/14/14 17:40:15 to 01/14/14 17:40:15

comment:12 Changed 7 years ago by jdemeyer

  • Dependencies #14804 deleted
  • Status changed from needs_work to needs_review

comment:13 Changed 7 years ago by jdemeyer

  • Description modified (diff)

This is a simple update and conversion to git which doesn't require the new build system.

comment:14 Changed 7 years ago by git

  • Commit changed from 07100d5d19cfd3128311a6e69e93709027272723 to f658dd9064212be726441b3356710b51f6c7b44b

Branch pushed to git repo; I updated commit sha1. New commits:

f658dd9Update checksums

comment:15 Changed 7 years ago by jdemeyer

  • Dependencies set to #14804
  • Modified changed from 01/15/14 10:36:01 to 01/15/14 10:36:01

comment:16 Changed 7 years ago by jdemeyer

  • Dependencies #14804 deleted

comment:17 follow-up: Changed 7 years ago by felixs

autotools is worthless without executables named $program-$version. take any autogenerated makefile and look out for AUTOMAKE=.* or ACLOCAL=.*. these are used whenever autogenerated files need to be refreshed.

please readd my patch that provides those executables (or switch to a sane build process that correctly uses --program-suffix as intended upstream).

(yes 14804 is not required. note that 14804 is *not* a new build system but helper scripts that will also enhance the old one.)

thanks

comment:18 in reply to: ↑ 17 ; follow-up: Changed 7 years ago by jdemeyer

Replying to felixs:

autotools is worthless without executables named $program-$version.

That's far from true, I have used this package many times. Perhaps the exacutables you mention are indeed needed for automake rules, but "worthless" is certainly not the right word.

please readd my patch that provides those executables

I'm certainly not going to add your exact patch as it has some comments which sound offending (I assume the comment next time RTFM in autofoo is addressed at me). If you want to add comments, better make them say something useful such that people can understand the purpose of the code.

More to the point: I think those version numbers are surely also needed for aclocal (and perhaps only for automake and aclocal?) and it seems your patch doesn't add those.

TL;DR: stop offending people, stop thinking your opinion is the One and Only Truth. Then people will be more willing to work with your patches.

comment:19 in reply to: ↑ 18 Changed 7 years ago by felixs

Replying to jdemeyer:

Replying to felixs:

autotools is worthless without executables named $program-$version.

That's far from true, I have used this package many times. Perhaps the exacutables you mention are indeed needed for automake rules, but "worthless" is certainly not the right word.

recreating Makefiles is done via automake rules. worthless is a bit underrating, but it shouldn't require sage-autotools-environment-variable-expert-knowledge to get something simple done.

I'm certainly not going to add your exact patch as it has some comments which sound offending (I assume the comment next time RTFM in autofoo is addressed at me). If you want to add comments, better make them say something useful such that people can understand the purpose of the code.

it took me two days to figure out and fix the autotools package, just for the sake of testing my demo on boxen. i was pretty pissed about the time wasted.

More to the point: I think those version numbers are surely also needed for aclocal (and perhaps only for automake and aclocal?) and it seems your patch doesn't add those.

yes. it would be better to rewrite the autotools package. i almost had when i found the spkg :|

TL;DR: stop offending people, stop thinking your opinion is the One and Only Truth. Then people will be more willing to work with your patches.

my apologies about the offense. maybe i should have removed the comment timely. apparently i didn't. i hope you still enjoy reading fine manuals :)

comment:20 follow-ups: Changed 7 years ago by jpflori

  • Reviewers set to Jean-Pierre Flori
  • Status changed from needs_review to needs_info
  • Summary changed from autotools package to Gitify autotools package and make it uptodate on 20140114
  • Work issues set to spkg history

The new package works fine. Just one question: why was the history in SPKG.Txt removed? Ok, it's not so useful, but...

And I won't go through the flamewar here, I just want an uptodate, working, gitified autotools pkgs whic can be used to (be able to) produce (minimal) patches for sage dev. Anything else can be postponed to a follow-up ticket.

comment:21 in reply to: ↑ 20 Changed 7 years ago by jdemeyer

Replying to jpflori:

The new package works fine. Just one question: why was the history in SPKG.Txt removed?

I think Volker told me that the history in SPKG.txt isn't going to be used anymore since the git transition.

comment:22 Changed 7 years ago by jdemeyer

  • Status changed from needs_info to needs_review
  • Work issues spkg history deleted

comment:23 follow-up: Changed 7 years ago by jpflori

Hummm, this means one will have to use git and scripting rather than opening a text file to get a quick overview of what happened to the package? And what about ancien history where the automagically git commits taken from mercurial commits don't necessarily reflect what used to be indicated in the history part of SPKG.txt? I expect to have to fight with Volker, but I don't really think its the best idea...

comment:24 in reply to: ↑ 23 Changed 7 years ago by jdemeyer

Replying to jpflori:

Hummm, this means one will have to use git and scripting rather than opening a text file to get a quick overview of what happened to the package? And what about ancien history where the automagically git commits taken from mercurial commits don't necessarily reflect what used to be indicated in the history part of SPKG.txt? I expect to have to fight with Volker, but I don't really think its the best idea...

I agree with Volker that having the same information in multiple places (version numbers, history) will lead to mistakes. For example, my Mercurial-era release management script checked that the version number in SPKG.txt matched the actual version number. You should see how many times that failed... If the information is not there, then it cannot be wrong.

Old SPKG.txt history can still be retrieved using the usual git tools.

comment:25 follow-up: Changed 7 years ago by jpflori

  • Status changed from needs_review to positive_review

Ok, two against one :) (Then I guess we could get rid of the .p? part of package version as well and just check for changes in the build/pkgs/?/ folder to decide to rebuild a pkg.)

comment:26 in reply to: ↑ 20 Changed 7 years ago by felixs

u/felixs/ticket/prior_15123 now points to my old branch rebased onto the ticket branch to be on the safe side, i have removed (as in 'edited history') anything that might look offensive.

Replying to jpflori:

Anything else can be postponed to a follow-up ticket.

that's fine with me.

comment:27 follow-up: Changed 7 years ago by jdemeyer

felixs, do you want to create a follow-up ticket for that?

comment:28 in reply to: ↑ 27 Changed 7 years ago by felixs

Replying to jdemeyer:

felixs, do you want to create a follow-up ticket for that?

if it turns out to make sense. i am unsure. i consider the package far too complex and nonstandard (wrt to how other packages work and wrt how autotools packages work on other platforms). perhaps it should better be replaced by simpler packages with simpler build rules...

maybe time will tell. but don't wait for me.

thanks

comment:29 in reply to: ↑ 25 Changed 7 years ago by jdemeyer

Replying to jpflori:

and just check for changes in the build/pkgs/?/ folder to decide to rebuild a pkg.

How would you "just check" for that?

comment:30 Changed 7 years ago by jpflori

Using git :)

comment:31 follow-up: Changed 7 years ago by jpflori

Or just timestamps now things are not within a tarball anymore.

comment:32 in reply to: ↑ 31 Changed 7 years ago by jdemeyer

Replying to jpflori:

Or just timestamps now things are not within a tarball anymore.

"just timestamps"... timestamps of what? There isn't a single file who's timestamp could be used. Using multiple files (or all files under build/pkgs/$PKG) makes the implementation harder...

comment:33 follow-up: Changed 7 years ago by jpflori

Come on, let's just stop that senseless discussion, that was just a joke (though with Makefile magic it should not be impossible to add all files within a directory as dependencies of a target).

comment:34 in reply to: ↑ 33 Changed 7 years ago by jdemeyer

Replying to jpflori:

Come on, let's just stop that senseless discussion

though with Makefile magic it should not be impossible to add all files within a directory as dependencies of a target.

I hope you see the contradiction between these two sentences...

comment:35 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:36 Changed 7 years ago by vbraun

  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.