On Tue, Dec 15, 2009 at 7:05 AM, Phil Hagelberg wrote:
> Yep, this will be changed in the next release of leiningen. The default
> build will only AOT namespaces that actually need it to
> function. Naturally you will still be able to build jars that AOT
> everything, but you will have to specifi
B Smith-Mannschott writes:
> This issue has also been brought up in connection with leiningen,
> which currently AOT-compiles everything as part of its normal build.
> My impression is that it would be smarter to be selective about what
> gets AOT compiled, and what doesn't.
Yep, this will be ch
On Dec 14, 2009, at 7:16 AM, B Smith-Mannschott wrote:
>> Then, to depend upon only the source jar in a downstream project, one
>> would simply add a 'classifier' element to the dependency element:
>>
>>
>>com.ashafa
>>clutch
>>1.0-SNAPSHOT
>>sources
>>
>
> Hmmm... but in the Cl
2009/12/14 Meikel Brandmeyer
> Hi Laurent,
>
> Am 14.12.2009 um 09:43 schrieb Laurent PETIT:
>
> > But from what I (currently) know, AOTing jars should be harmless.
> > So maybe the problem is that there's a bug in the new branch, and this
> bug needs to be corrected ?
>
> No. The inner workings
Hi Laurent,
Am 14.12.2009 um 09:43 schrieb Laurent PETIT:
> But from what I (currently) know, AOTing jars should be harmless.
> So maybe the problem is that there's a bug in the new branch, and this bug
> needs to be corrected ?
No. The inner workings of Clojure might change. AOT compiled code
On Mon, Dec 14, 2009 at 11:31, Chas Emerick wrote:
> There are certainly binary incompatibility issues between the
> different versions/branches -- that'll settle out as the core matures,
> and IIUC, especially once c-in-c becomes a reality.
>
> However, only providing libraries as source (non-AOT
There are certainly binary incompatibility issues between the
different versions/branches -- that'll settle out as the core matures,
and IIUC, especially once c-in-c becomes a reality.
However, only providing libraries as source (non-AOT-compiled) jars
whenever possible only shifts the problem aro
Hello,
Interesting return of experience.
But from what I (currently) know, AOTing jars should be harmless.
So maybe the problem is that there's a bug in the new branch, and this bug
needs to be corrected ?
2009/12/13 dysinger
> So in my experiments with using clojure / contrib w/ the "new" bra
Hi,
I like to suggest the following policy: publish libraries as jarred-
up .clj sources and AOT them locally when building an application.
Leiningen could sure help here and everen cache different compiled
versions dependening on the clojure version.
IIRC this is what Debian does with elisp pack
On Mon, Dec 14, 2009 at 07:26, mac wrote:
> On Dec 13, 11:44 pm, dysinger wrote:
>> So in my experiments with using clojure / contrib w/ the "new" branch,
>> I've noticed a pattern of binary incompatibility. Jars pushed to
>> clojars, maven repos and other places that are are unnecessarily
>> AO
On Dec 13, 11:44 pm, dysinger wrote:
> So in my experiments with using clojure / contrib w/ the "new" branch,
> I've noticed a pattern of binary incompatibility. Jars pushed to
> clojars, maven repos and other places that are are unnecessarily
> AOTed, don't work with clojure "new". I noticed th
So in my experiments with using clojure / contrib w/ the "new" branch,
I've noticed a pattern of binary incompatibility. Jars pushed to
clojars, maven repos and other places that are are unnecessarily
AOTed, don't work with clojure "new". I noticed the same thing going
from clojure 1.0 to clojure
12 matches
Mail list logo
