-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Jonathan,
thanks for considering this.
> If nothing else, it would require all the module-specific output
> directories to be created ahead of time, so that javac can
> determine which ones to use
Why would that be the case? It is not necessary to create them now so
why would using asterisk change that?
> It has always been the case that a single compilation for
> different packages from different libraries would result in the
> classes being placed in a single output directory hierarchy, and
> that the classes could then be selectively packaged into different
> files like .jar files.
It has also always been the case that the compiler had no notion of
projects/artifacts/modules but just of plain source files. ;) That
changed, too, so why not do the same for class files?
> If you're compiling modules together, why could you not do
> something similar?
I have no particular use case (except writing some demos) but I would
guess that it would make it more comfortable for existing tools to
move towards multi-module compilation.
I also like this idea for its symmetry. You can define input the
compilers input, sorted by modules, with *, so why not do the same for
its output? Conceptually that should be obvious (which does not mean
that there are not plenty if reasons against it).
so long ... Nicolai
On 23.01.2017 20:51, Jonathan Gibbons wrote:
> Nicolai,
>
> I don't think this proposal is a good way to go. If nothing else,
> it would require all the module-specific output directories to be
> created ahead of time, so that javac can determine which ones to
> use, which would require additional setup commands to be executed
> after a "make clean" or its equivalent in other build systems.
>
> Also, I note that the output directory is typically never the
> final location for the compiled classes; it is typically just a
> "staging area". It has always been the case that a single
> compilation for different packages from different libraries would
> result in the classes being placed in a single output directory
> hierarchy, and that the classes could then be selectively packaged
> into different files like .jar files. If you're compiling modules
> together, why could you not do something similar?
>
> -- Jon
>
>
>
> On 01/21/2017 02:00 AM, Nicolai Parlog wrote:
>> Hi!
>>
>> Another feature request from the trenches regarding multi-module
>> compilation. (It is possible that there was a similar thread a
>> couple of days/weeks (?) back but I didn't find it.)
>>
>> It would be nice to have the ability to specify module specific
>> target folders, so they do not automatically end up in
>> `<whatever-was-given-to-d>/<module-name>`.
>>
>> It seems obvious (which could very well make it stupid) to reuse
>> the asterisk here and allow something like
>>
>> javac --module-path mods --module-source-path
>> "./*/src/main/java" -d "./*/target/classes" -module
>> initial.module
>>
>> I have not thought through how this might or might not work with
>> multiple module source paths. It looks like the only tractable
>> approach would be to not allow more than one -d element.
>>
>> so long ... Nicolai
>>
>>
>>
>
- --
PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJYiF/pAAoJEMo7rS6czNUJx9wP/338lKXahsdkn2x0I3BDRNFK
t2IPuDTyFtzeEEuJjDkFVSIsGxfIWsZRtvUpZT23gZrOQikR+lqmdawYUmob+7pd
ir+1MmxJjUWoVCxd/6n557gxtcCJxIcUUcTwMthRwepnZdEQBHfxgd1Qs6QPJlvK
h87wvAubDjIn7ssm5PQnAB4i/kHbSBs8ZZFFcdzQpXPN/9dMMGwKliYXfYponzfo
79rQORyt5MBufj+ufPyzu7PixbfSXADqFOvofzSo793vE7jpPD0lfBOofeVIwoWq
0CK3FREapTDYiv3NNKtLt1no8/AGP5nTR//QmhAf2V+fmw0brVbmyBNKAfPqwQKN
3XCX+MfWaLBSonGMyvihXBlSiFT5feqsBPkBiRTMk7QI2eR3NADVvWCQwM8uvO+p
Yul6XOqTKoFf3EWJDTyg3X5vRqcuX+n7utI9ii4Jw2R1fUmO1cYMk6jHP4pqmQ/t
tgrEj0b8kqNKBLrWcndap76KgRIGBZRmmvZGe1EXqELt1x/72T/0PclfcuArHVjq
nYJz/iranyR3s/MtAk50krvgSrGTcbjD+YCf6APNKW06vCvKX7PXUY+i2e5FCbNB
zGka80aricdsmq5De9jF7+g7/mQWodO9lUlgur3Vh042Qe3DD8pwoLcrMLLm8mNQ
fjldcnfa+hXTe+aongGg
=H7sH
-----END PGP SIGNATURE-----
