| hansg has joined this channel (n=hans@ip32-174-211-87.adsl2.static.versatel.nl).
| 11:03
|
| * rdieter owes svahl another adult beverage of choice
| 11:04
|
| hansg
| Hi all, I'm present for the fpc meeting.
| 11:04
|
| * spot looks around for FPC members
| 11:04
|
| f13
| I'm lurking today
| 11:04
|
| * spot sees abadger1999, tibbs|h, rdieter, Rathann
| 11:06
|
| spot
| and hansg, of course. ;)
| 11:06
|
| abadger1999
| I'm here.
| 11:06
|
| * rdieter puts fpc hat on
| 11:06
|
| Rathann
| present
| 11:06
|
| hansg
| Hi all, sorry for all the missed meetings, my schedule just does not seem to align properly with the fpc meetings
| 11:07
|
| spot
| ubertibbs: ping
| 11:07
|
| ubertibbs
| Yep.
| 11:07
|
| racor has joined this channel (n=rc040203@HSI-KBW-078-043-127-065.hsi4.kabel-badenwuerttemberg.de).
| 11:07
|
| spot
| there's racor
| 11:07
|
| ubertibbs
| Sorry, just had to get someone out of my office.
| 11:07
|
| abadger1999
| heh
| 11:07
|
| racor
| yep, I am here ... at least for the next couple of minutes ;)
| 11:08
|
| spot
| okay, lets get the easy one out of the way first
| 11:08
|
| spot
| http://overholt.fedorapeople.org/EclipsePlugins.diff
| 11:08
|
| Topicubertibbs sets the channel topic to "Packaging Committee Meeting".
| 11:08
|
| spot
| basically, andrew overholt asked for changes to the eclipse guidelines to reflect the changes in eclipse 3.4
| 11:08
|
| ubertibbs
| This is simply necessary to adapt to changes in the underlying software (and to fix a couple of typos); I think we should just do it.
| 11:09
|
| spot
| ubertibbs: yep.
| 11:09
|
| spot
| +1 from me
| 11:09
|
| rdieter
| +1
| 11:09
|
| abadger1999
| +1
| 11:09
|
| racor
| +1
| 11:09
|
| ubertibbs
| +1
| 11:10
|
| spot
| okay, thats +5
| 11:10
|
| Rathann
| +1
| 11:10
|
| spot
| next item: http://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code
| 11:10
|
| spot
| mtasaka made a new draft at the bottom of that page which is a lot cleaner
| 11:10
|
| hansg
| +1
| 11:11
|
| hansg
| That +1 is for the eclipse changes, man you are all fast
| 11:11
|
| spot
| under "Revised proposition"
| 11:11
|
| spot
| for me, this revised proposition is a lot clearer and simpler
| 11:12
|
| ubertibbs
| That whole thing is confusing.
| 11:13
|
| ubertibbs
| Are we only considering the part between "Revised proposition" and "Note"?
| 11:13
|
| spot
| ubertibbs: and the example
| 11:13
|
| Rathann
| it says [SOLVED] but I don't see a clear solution to "Installed C Codes"
| 11:13
|
| spot
| hmm, i think this may make things a bit simpler
| 11:16
|
| spot
| https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code_spot
| 11:16
|
| spot
| those would be the guideline changes
| 11:16
|
| * hansg thinks we need to tell them just to fix the gem buildsystem, or hack around it
| 11:16
|
| abadger1999
| Rathann: I think that's here: " Installed C codes (usually under %{geminstdir}/etc) may be removed even if gem contents %{gemname} reports that installed C codes should be found there. "
| 11:17
|
| hansg
| Installing under builddir so as to avoid having buildroot coded into the binaries is completely fscked up, we want neither the buildroot nor the builddir encoded into the binaries !!!
| 11:17
|
| Rathann
| hansg: +1
| 11:17
|
| ubertibbs
| I have to agree.
| 11:18
|
| ubertibbs
| I mean, we could just build normally and then call sed on the binaries to pass the check if that's all we care about.
| 11:18
|
| warren has joined this channel (n=warren@redhat/wombat/warren).
| 11:18
|
| Rathann
| and what's with the compilation-on-install?
| 11:18
|
| ubertibbs
| The bottom line is that we're dealing with a broken system here. How do we address that?
| 11:19
|
| * hansg votes for sending this back to the drawing board
| 11:19
|
| spot
| also, we have gems in Fedora right now
| 11:19
|
| hansg
| ubertibbs, patch the hell out of it until it does what we want
| 11:19
|
| spot
| so presumably, things are worse than this in the current guidelines
| 11:19
|
| ubertibbs
| We have plenty of gems, but how many of them have compiled C code in them?
| 11:19
|
| hansg
| or even better explain very patiently and clearly to upstream and ask them to add a switch which does what we want ?
| 11:19
|
| ubertibbs
| There's no question for regular gems that contain only Ruby code.
| 11:20
|
| Rathann
| I guess we could approve it as a temporary workaround of the current problems
| 11:20
|
| Rathann
| but only if the maintainer promises to work with upstream to resolve these problems
| 11:20
|
| ubertibbs
| And another question: should the check that all of this hacks around simply be disabled?
| 11:20
|
| hansg
| Rathann, small +1 (its just so d*mn ugly)
| 11:20
|
| ubertibbs
| I mean, what are we working around here?
| 11:20
|
| ubertibbs
| The produced binaries include the buildroot as a string somewhere. Is this actually something we care about?
| 11:21
|
| hansg
| ubertibbs, we are working around a check, which checks that no compilation was done during %install, something which can be very bad when there is no DESTDIR, and thus we redefine PREFIX to get installed to the right place
| 11:21
|
| ubertibbs
| Yes, the rpm check is there to catch potential breakage. But is there actual breakage in this case?
| 11:21
|
| ubertibbs
| So is the point of this to work around the check, or is is to force the broken build system to do its building in %build instead of %install?
| 11:22
|
| hansg
| ubertibbs, it may happen to just work here, but its *wrong wrong wrong* and the debuginfo will be completely fscked up because of this
| 11:23
|
| ubertibbs
| Because honestly the included example doesn't look all that bad to me.
| 11:23
|
| * Rathann has no idea about ruby and its gems
| 11:23
|
| spot
| no, i think this is because the "gem" command embeds the install path passed to it in compiled libraries
| 11:23
|
| spot
| if i run: gem install --local --install-dir %{buildroot}%{gemdir
| 11:23
|
| spot
| then "%{buildroot}%{gemdir}" is going to get embedded into libraries
| 11:24
|
| spot
| whereas, if i run: gem install --local --install-dir ./%{gemdir}
| 11:24
|
| hansg
| spot, so you think that the source file paths in the debuginfo will be right?
| 11:24
|
| spot
| hansg: i have no idea, but again, i'm not sure if the debuginfo is useful anyways for ruby gems
| 11:24
|
| spot
| having the %{buildroot} embedded in C libraries is obviously bad
| 11:25
|
| hansg
| spot, well if they have native code, it might be useful
| 11:25
|
| spot
| hansg: only if a debugger can parse it sanely
| 11:25
|
| hansg
| hmm, it seems we are not alone with this problem, see: http://pkg-ruby-extras.alioth.debian.org/rubygems.html
| 11:27
|
| hansg
| and: http://pkg-ruby-extras.alioth.debian.org/upstream-devs.html
| 11:27
|
| ubertibbs
| So, honestly, looking at the provided example spec, I don't see anything stomach churning.
| 11:27
|
| spot
| yeah. it is a hack, but its not the worst hack ever.
| 11:28
|
| hansg
| I think we should ask the Fedora ruby guys to team up with the debian ruby guys and try to get this improved upstream
| 11:28
|
| spot
| hansg: yes, but i'd also like to let them document this interim workaround
| 11:28
|
| hansg
| I can live with this, under the condition that some serous attempts are made to remedy this properly
| 11:29
|
| Rathann
| well, as long as the final result is sane I'm not against this
| 11:29
|
| abadger1999
| ubertibbs: +1
| 11:29
|
| ubertibbs
| I don't know how we can put conditions on a guideline like that.
| 11:29
|
| Rathann
| although I find it odd that passing install-dir relative to current dir matters somehow
| 11:30
|
| ubertibbs
| Now, what I would really like to see is a package that does this, so we can look at the result and make sure it is actually sane.
| 11:30
|
| spot
| i think the best we can do is to vote on this and request that the ruby folks (mamoru and david lutterkort) try to get this fixed upstream
| 11:30
|
| Rathann
| ubertibbs: +1, I too would like to have a testable src.rpm
| 11:31
|
| abadger1999
| lutter owns the rubygem package as well.
| 11:31
|
| spot
| we can ask for an example SRPM
| 11:31
|
| ubertibbs
| So, I hate to make them go through the cycle again.
| 11:31
|
| spot
| as do i, but if you guys are uncomfortable with the draft as is...
| 11:32
|
| ubertibbs
| Based on what I can see, I can vote for this but my concern is that we approve it and then rpm goes and does something bizarre with it.
| 11:32
|
| spot
| fwiw, i'm +1 on this, with the request to fix this properly in the gem install command
| 11:32
|
| hansg
| +1 (also with the request to fix this properly in the gem install command)
| 11:33
|
| abadger1999
| I'm willing to vote +1. For a hack it's pretty clean and it's an improvement on where we are today.
| 11:33
|
| rdieter
| +1 (ditto)
| 11:33
|
| Rathann
| +1 as well
| 11:33
|
| ubertibbs
| We need to ask in the future that guidelines changes come with an actual package attached so that we can look over things.
| 11:33
|
| abadger1999
| <nod>
| 11:33
|
| ubertibbs
| Anyway, +1 to the proposal.
| 11:33
|
| spot
| okay, there is +5 in there
| 11:34
|
| spot
| it passes with the request
| 11:34
|
| spot
| Next item: http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
| 11:34
|
| spot
| there are a few things in here
| 11:34
|
| spot
| the first one is a followup from http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction:_fontconfig_(2008-10-12))
| 11:35
|
| spot
| we approved it, pending upstream feedback
| 11:35
|
| ubertibbs
| Personally I have no real problem with magicalness in specs and hiding things behind macros.
| 11:35
|
| ubertibbs
| But I know that others here have disagreed in the past.
| 11:35
|
| spot
| well, in the case of fonts, this is already happening
| 11:36
|
| spot
| this effort is to standardize the macros
| 11:36
|
| ubertibbs
| It isn't as if we haven't approved GHC and Java guidelines in the past after asking them to hide more things behind macros.
| 11:36
|
| abadger1999
| spot:agreed. The macros have already happened.
| 11:36
|
| ubertibbs
| I do with the "set of font packages" links actually had some spec files I could look at.
| 11:37
|
| hansg
| Fonts_packaging_automation, +1 (I'm assuming the actual macros will get vetted during the review of the package)
| 11:37
|
| spot
| I'm +1 here as well
| 11:37
|
| ubertibbs
| hansg: I don't think it is safe to assume that.
| 11:37
|
| abadger1999
| +1
| 11:37
|
| hansg
| ubertibbs, even then I'm still +1, I don't want the fpc to go vetting each and every macro ever introduced / used
| 11:38
|
| Rathann
| I remember reading that earlier on the mailing list, I liked it and I see my comments have been taken into account, so +1
| 11:38
|
| racor
| -1
| 11:38
|
| Rathann
| however I think it should be named fonts-* not fontpackages-*
| 11:38
|
| * hansg wonders whats in a name
| 11:39
|
| ubertibbs
| I'm getting blown over by the bureaucracy here. Can this whole thing be condensed to "We want to add five macros"?
| 11:39
|
| racor
| to me, using the package is a massive mistake
| 11:39
|
| spot
| ubertibbs: and take into account the avail.d/ changes we saw before
| 11:39
|
| racor
| ubertibbs: Yes and move it to fedora-rpm-config
| 11:40
|
| ubertibbs
| racor: Can you articulate your objections? I would really like to hear them, but I'm concerned that IRC is not a good medium for that.
| 11:40
|
| racor
| I am objecting the macros
| 11:40
|
| ubertibbs
| Where do you actually see the macros?
| 11:41
|
| racor
| once a macro is in, you can hardly ever get rid of them
| 11:41
|
| ubertibbs
| It's like this proposal is a long-winded document but doesn't actually include the changes they want to make.
| 11:41
|
| racor
| they are part of the src.rpm
| 11:41
|
| * f13 wonders what racor suggests as an alternative
| 11:41
|
| ubertibbs
| I guess I'll go unpack it now. They should be in the actual proposal.
| 11:42
|
| f13
| mass cut/paste ?
| 11:42
|
| spot
| http://fpaste.org/paste/143
| 11:43
|
| Rathann
| f13: python and perl package specfiles define python and perl paths themselves, so there is a precedent
| 11:43
|
| ubertibbs
| racor: Are you objecting to things like %_fontbasedir %{_datadir}/fonts
| 11:43
|
| racor
| ubertibbs: yes.
| 11:43
|
| ubertibbs
| Thinking instead that packages should just use %{_datadir}/fonts if that's what they mean?
| 11:43
|
| f13
| Rathann: precedent, or lazyness?
| 11:43
|
| spot
| f13: precedent. these macros are useful.
| 11:43
|
| racor
| furthermore you would have to BR: fontpackages-devel in all fonts*specs
| 11:43
|
| spot
| (well, at least the python/perl ones)
| 11:43
|
| f13
| spot: I meant precedent to leaving them in the top of .spec files rather than putting them in redhat-rpm-config
| 11:44
|
| ubertibbs
| racor: Then do you object to, say, the %{_R_make_search_index} macro from the R guidelines?
| 11:44
|
| Rathann
| well, fontbasedir seems redundant, it's used only once
| 11:44
|
| spot
| f13: the point being that having standardized macros makes it easier for new packagers
| 11:44
|
| f13
| spot: I don't think you're seeing my argument.
| 11:44
|
| ubertibbs
| Or the %ghc_preinst_script macro from the Haskell guidelines?
| 11:44
|
| f13
| spot: I wasn't buying the macros being in the top of python spec files as 'precedent for not having site wide macros'
| 11:44
|
| Rathann
| f13: I meant it as a bad example :)
| 11:45
|
| Rathann
| they should be moved out of these specs into rpm config
| 11:45
|
| racor
| the perl macros are implemented in *-rpm-config, not in a separate package
| 11:45
|
| Rathann
| not necessarily a separate package
| 11:45
|
| spot
| racor: so, you'd be okay with these macros in *-rpm-config ?
| 11:46
|
| racor
| ... and you can hardly get rid of them
| 11:46
|
| Rathann
| well, racor has a point about not adding BR: fontpackages-devel to every font package
| 11:46
|
| rdieter
| it's not uncommon for initial implementations to start elsewhere, and once proven, move into -rpm-config.
| 11:46
|
| racor
| spot: no, I am against any vendor-proprietary macros.
| 11:46
|
| ubertibbs
| I'm just trying to understand racor's objection. Is it that we shouldn't be adding macros, ever? Or that these macros don't add enough value? Or is it something else?
| 11:46
|
| racor
| I am not opposed to upstream rpm providing macros
| 11:47
|
| rdieter
| Rathann: that's a policy decision made by font sig, if that's what they want.
| 11:47
|
| * hansg watches the clock
| 11:47
|
| spot
| so, basically, the only thing for FPC here is whether we approve the macros and use of avail.d
| 11:47
|
| Rathann
| rdieter: sure, if someone takes care of that, then it's fine, but I do object slightly to adding "just one line" to every font spec
| 11:48
|
| rdieter
| Rathann: also, font sig's job, imo, to "take care of that". :)
| 11:48
|
| racor
| rdieter: do we care about other people's ponys?
| 11:48
|
| Rathann
| having said that, I'm still in favour of this draft
| 11:48
|
| ubertibbs
| Personally I have no problems with adding additional macros if it makes things simpler for the packagers and makes the packages simpler to comprehend.
| 11:48
|
| spot
| Can we do a vote?
| 11:49
|
| racor
| spot: i this applies, you can shut down this FPC
| 11:49
|
| rdieter
| racor: as long is they don't interfere, and play nice with other ponys.
| 11:49
|
| racor
| it's our job to review other group's proposal.
| 11:49
|
| ubertibbs
| And I don't think the committee as a whole does, either, because we've approved Haskell and Java and R in the past, with their macros included.
| 11:49
|
| spot
| racor: and... we are.
| 11:49
|
| racor
| ubertibbs ... yes, mistakes to learn from.
| 11:50
|
| ubertibbs
| Hardly.
| 11:50
|
| ubertibbs
| I mean, this wasn't even raised as an objection then.
| 11:50
|
| ubertibbs
| We _asked_ them to add macros to Java and Haskell.
| 11:50
|
| * f13 hasn't noticed the world ending because java packages have macros
| 11:51
|
| racor
| ubertibbs: Did we?
| 11:51
|
| Rathann
| spot: +1 on fonts packaging automation
| 11:51
|
| ubertibbs
| It makes the packages reasonable instead of having 50 lines of identical shell code pasted into them.
| 11:51
|
| spot
| +1 from me
| 11:51
|
| hansg
| spot: +1 on fonts packaging automation
| 11:51
|
| ubertibbs
| +1 from me.
| 11:51
|
| racor
| -1 from me
| 11:51
|
| rdieter
| +1 (there's good and bad uses of macros, this is an example of the good kind, imo)
| 11:51
|
| ubertibbs
| racor: If you want the reference where we asked the Java folks to add the macros, I will dig it out for you.
| 11:52
|
| spot
| abadger1999: would you like to vote?
| 11:52
|
| abadger1999
| +1
| 11:52
|
| spot
| okay, thats 6 for and 1 against, it passes
| 11:52
|
| spot
| we have two other items on the "todo" list for today, but i'm not sure they are ready for review yet
| 11:52
|
| spot
| JavaScript and Python Virtual Provides
| 11:53
|
| spot
| abadger1999: both of these are yours, i believe
| 11:53
|
| abadger1999
| spot: Too busy with upstream python issues.
| 11:53
|
| spot
| abadger1999: okay, then, are there any other issues for today?
| 11:53
|
| abadger1999
| I owe the committee a pros and cons table for the javascript guidelines.
| 11:53
|
| abadger1999
| https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html
| 11:53
|
| abadger1999
| That's an additional issue.
| 11:54
|
| f13
| there was the message I posted regarding review guidelines vs package guidelines
| 11:54
|
| ubertibbs
| Yes, f13's request.
| 11:54
|
| spot
| if no one is opposed, i can go over the review guidelines and make sure they're all expressed in the packaging guidelines
| 11:55
|
| abadger1999
| spot: +1
| 11:55
|
| f13
| i was kind of hoping some kind soul would do it so that spot or I wouldn't have to (:
| 11:55
|
| spot
| f13: i know them well enough, it won't take me too long
| 11:55
|
| ubertibbs
| +1 for someone else doing it.
| 11:55
|
| ubertibbs
| I so hate working in the wiki.
| 11:55
|
| spot
| okay, since i am not hearing opposition, i'll just tackle that
| 11:56
|
| f13
| ubertibbs: you should really try lmacken's vim plugin for firefox/wiki
| 11:56
|
| spot
| as to the FHS stuff, i'm not opposed with making it a MUST that packages follow the FHS
| 11:56
|
| ubertibbs
| f13: I used to use mozex, but it doesn't work with ff3.
| 11:56
|
| spot
| the only thing that gives me concern is cross compilers
| 11:57
|
| ubertibbs
| Well, remember that /spu was a mistake that has been fixed.
| 11:57
|
| spot
| i know they need a toplevel in /usr
| 11:57
|
| Rathann
| is FHS sane now? if so, no objections
| 11:57
|
| racor
| spot: why?
| 11:57
|
| ubertibbs
| And I tried to do something about cross-compilers and was flamed so much for my trouble that I gave up.
| 11:57
|
| spot
| racor: that was what i thought, keeping in mind that i'm not an expert here
| 11:57
|
| racor
| the spu package is simply broken.
| 11:57
|
| spot
| racor: do cross compilers need to violate the FHS?
| 11:57
|
| f13
| racor: cross compilers need /usr/<target>/ don't they?
| 11:57
|
| hansg
| f13, that is preferred way of doing things, yes
| 11:58
|
| racor
| spot,f13: Right, the need $exec_prefix/<target>
| 11:58
|
| f13
| is that allowed by the FHS ?
| 11:58
|
| QuitSonar_Gal has left this server (Read error: 110 (Connection timed out)).
| 11:58
|
| abadger1999
| spot, racor: Is the crosscompiler location specified in the GNU coding standard?
| 11:58
|
| racor
| f13, no, but it's common practice ever since GCC is around
| 11:58
|
| ubertibbs
| racor: So when spot said the same thing as you just said, you replied "why?".
| 11:58
|
| * abadger1999 knows that libexecdir is.
| 11:58
|
| hansg
| f13, AFAIK no, but it is how the whole world does it
| 11:58
|
| f13
| so this is exactly what spot was asking about
| 11:59
|
| ubertibbs
| It's no wonder why people are confused.
| 11:59
|
| spot
| so, i don't think the FHS specifies where cross toolchains should go
| 11:59
|
| f13
| cross compilers don't adhere to the FHS, so that's a concern if we were to make FHS mandatory.
| 11:59
|
| Rathann
| f13: we could make it mandatory except for cross-compilers
| 11:59
|
| ubertibbs
| "As exceptions..... libexec.... cross compilers..."
| 11:59
|
| f13
| (or more correctly the FHS doesn't adhere to cross compilers)
| 11:59
|
| racor
| spot, f13: the why was aiming at the spu toolchain. it is badly packaged
| 12:00
|
| f13
| racor: spu was the recent example, regardless of /spu, it also had /usr/spu/
| 12:00
|
| spot
| really, this boils down to a lack of guidelines for how to package cross toolchains
| 12:00
|
| racor
| there is no need for /spu, GCC however needs /usr/spu
| 12:00
|
| f13
| ubertibbs: clearly all our guidelines must have 2 listed exceptions to them. Lets make /that/ a guideline, with exceptions (:
| 12:01
|
| abadger1999
| Looks like crosscompiler location is not specified in GNU standards.
| 12:01
|
| racor
| that said, /usr/<target> is the only case where GCC-cross toolchains deviate from the FHS.
| 12:01
|
| f13
| racor: please ignore the "/spu" part of the question. spot was mostly concentrating on /usr/spu which is common across all cross compilers we have (/usr/<target>)
| 12:01
|
| ubertibbs
| Everyone knows and agrees that /spu was a mistake caused by a macro that somehow was undefined. It was fixed immediately after it was brought up.
| 12:01
|
| spot
| okay, so we could make this a must and add the exception for the /usr/<target> for cross toolchains?
| 12:01
|
| racor
| spot: OK with me.
| 12:02
|
| spot
| are there any other places where enforcing the FHS strictly would cause us problems?
| 12:02
|
| abadger1999
| "with exceptions for libexecdir (specified in the GNU Coding Standards [LINK]) and /usr/target for crosscompilers"
| 12:02
|
| abadger1999
| http://www.gnu.org/prep/standards/standards.html#Directory-Variables
| 12:02
|
| hansg
| spot, +1
| 12:02
|
| ubertibbs
| I'm sure there are other problems, but we should simply address them when they come up.
| 12:03
|
| racor
| this of course should not invalidate attempts to make GCC better compliant to the FHS.
| 12:03
|
| spot
| abadger1999: looks good to me.
| 12:03
|
| abadger1999
| +1 from me :-)
| 12:03
|
| racor
| +1
| 12:03
|
| Rathann
| +1
| 12:03
|
| spot
| +1
| 12:03
|
| rdieter
| +1
| 12:04
|
| spot
| ubertibbs: would you like to chime in?
| 12:04
|
| ubertibbs
| +1
| 12:04
|
| ubertibbs
| sorry
| 12:04
|
| spot
| okay, thats +5 easily
| 12:04
|
| spot
| any other items?
| 12:04
|
| spot
| none from me
| 12:04
|
| Rathann
| so javascript and python are postponed?
| 12:05
|
| spot
| Rathann: yes
| 12:05
|
| Rathann
| js looks fine to me though
| 12:05
|
| Rathann
| we've already discussed it too
| 12:05
|
| abadger1999
| Rathann: Yeah... I've been running across problems with my own draft.
| 12:05
|
| Rathann
| ah
| 12:06
|
| hansg
| For those interested in cross compiler guidelines the embedded SIG (which is sort of dead atm) has a blurb here: http://fedoraproject.org/wiki/Extras/SIGs/Embedded/CrossCompiling
| 12:06
|
| abadger1999
| Rathann: I want to change javascript to be more like static libraries.
| 12:06
|
| Rathann
| ok then
| 12:06
|
| ubertibbs
| It's more along the lines of it not really being reasonable to do it in some other way.
| 12:06
|
| abadger1999
| But that has the usual static library issues so it needs evaluation.
| 12:06
|
| hansg
| The <exex-prefix>/<target> is specified in gcc's INSTALL document
| 12:06
|
| Rathann
| abadger1999: not more like java .jars?
| 12:06
|
| ubertibbs
| BTW, I just approved a puthon package that includes some portion of jquery. Maybe I shouldn't have done that; I'm not really sure.
| 12:07
|
| abadger1999
| Rathann: I'm only passingly familiar with .jars What do you see as a parallel?
| 12:07
|
| abadger1999
| ubertibbs: <nod> Until we get JavaScript Guidelines, that's probably what we should do. We'll definitely want to clean those up after wards, though.
| 12:08
|
| * hansg has got to go now
| 12:09
|
| Rathann
| when not used via http, both jars and js have be put into path or symlinked to be usable by an application
| 12:09
|
| hansg
| Next meeting same time ? I still really would like to see a different time.
| 12:10
|
| hansg
| Bye all/
| 12:10
|
| Rathann
| but they're not "linked in" as is the case with static libs
| 12:10
|
| Rathann
| bye hansg
| 12:10
|
| Rathann
| abadger1999: ^
| 12:10
|
| abadger1999
| So js is a bit more involved. Because it is almost always served over http, having tons of little files creates a huge latency.
| 12:10
|
| spot
| feel free to keep chatting guys, but i'm calling the meeting
| 12:11
|
| Rathann
| true
| 12:11
|
| abadger1999
| But to organize your code you want to have lots of little files.
| 12:11
|
| Rathann
| thanks spot :)
| 12:11
|
| abadger1999
| Thanks spot!
| 12:11
|
| abadger1999
| So with dojo, I discovered that they distribute a tarball with tons of individual files, a way to specify dependencies between them, and a script to "compile" them into a single file.
| 12:12
|
| Rathann
| ah
| 12:12
|
| Rathann
| neat, but do we really want to do that?
| 12:12
|
| abadger1999
| heh. Not sure :-)
| 12:12
|
| abadger1999
| If we did, then it would be like static libraries.
| 12:13
|
| Rathann
| yes
| 12:13
|
| nim-nim
| all: thanks for approving the fonts stuff
| 12:13
|
| abadger1999
| If we don't, applications will be very slow by default.
| 12:13
|
| Rathann
| abadger1999: what's the slowdown? 10%? 50%?
| 12:13
|
| abadger1999
| Rathann: I found it depends on the http server. For a python app using CherryPy, it was seconds vs minutes.
| 12:14
|
| abadger1999
| Rathann: When I switched it to apache, it was still seconds vs over a minute.
| 12:15
|
| Rathann
| I'm thinking about some sort of caching/preprocessing, i.e. build one file out of all the dependent js files but rebuild it if any of them gets updated
| 12:16
|
| abadger1999
| <nod> You mean dynamically?
| 12:16
|
| Rathann
| I guess
| 12:16
|
| abadger1999
| mod_javascript :-)
| 12:16
|
| Rathann
| heh
| 12:16
|
| Rathann
| just an idea
| 12:17
|
| Rathann
| all right, I have to go shop for food
| 12:17
|
| Rathann
| later folks
| 12:18
|
| abadger1999
| yeah. I think it's a good idea but there's no upstream project to do it ATM... We'd have to devote manhours to make it happen.
| 12:18
|
| abadger1999
| Rathann: Later!
| 12:18
|
| Rathann has left this channel ("Leaving.").
| 12:18
|
