override target: permits to override target setting an environment variable

[alalazo]

The following:

$export SPACK_TARGET_TYPE=x86_E5v2_IntelIB

will override the default target of the architecture:

$ spack spec zlib
Input spec
--------------------------------
zlib

Normalized
--------------------------------
zlib

Concretized
--------------------------------
zlib@1.2.10%gcc@4.8+pic+shared arch=linux-ubuntu14-x86_E5v2_IntelIB 

$ spack spec hdf5
Input spec
--------------------------------
hdf5

Normalized
--------------------------------
hdf5
    ^zlib@1.1.2:

Concretized
--------------------------------
hdf5@1.10.0-patch1%gcc@4.8+cxx~debug+fortran+mpi+pic+shared~szip~threadsafe arch=linux-ubuntu14-x86_E5v2_IntelIB 
    ^openmpi@2.0.2%gcc@4.8~java~mxm~pmi~psm~psm2~slurm~sqlite3~thread_multiple~tm~verbs+vt arch=linux-ubuntu14-x86_E5v2_IntelIB 
        ^hwloc@1.11.5%gcc@4.8 arch=linux-ubuntu14-x86_E5v2_IntelIB 
            ^libpciaccess@0.13.4%gcc@4.8 arch=linux-ubuntu14-x86_E5v2_IntelIB 
                ^libtool@2.4.6%gcc@4.8 arch=linux-ubuntu14-x86_E5v2_IntelIB 
                    ^m4@1.4.18%gcc@4.8+sigsegv arch=linux-ubuntu14-x86_E5v2_IntelIB 
                        ^libsigsegv@2.10%gcc@4.8 arch=linux-ubuntu14-x86_E5v2_IntelIB 
                ^pkg-config@0.29.1%gcc@4.8+internal_glib arch=linux-ubuntu14-x86_E5v2_IntelIB 
                ^util-macros@1.19.1%gcc@4.8 arch=linux-ubuntu14-x86_E5v2_IntelIB 
    ^zlib@1.2.10%gcc@4.8+pic+shared arch=linux-ubuntu14-x86_E5v2_IntelIB 

[becker33]

If I understand this correctly, adding specific targets (haswell, sandybridge, arm6, etc) would cover the first two portions of the your string, and adding the network into our architecture would cover the last portion. Would that completely cover your use case?

I don't like reintroducing site-generated targets like we had pre- spack#561. It prevents us from standardizing things. At the time of that PR we expected to need to add networks to the architecture spec eventually, now might be that time.

[alalazo]

If I understand this correctly, adding specific targets (haswell, sandybridge, arm6, etc) would cover the first two portions of the your string, and adding the network into our architecture would cover the last portion. Would that completely cover your use case?

@becker33 You're completely correct about my use case coverage. I don't mind if the PR is not merged, but I think it may be useful to fill the gap in the meanwhile. If you think it's distracting people, or fostering bad habits, feel free to close the PR on the LLNL repo.

That said, I see nothing wrong in having the possibility to customize the architecture with a site-dependent string. I understand that if we are going to distribute binary packages (and we are still pursuing that, right?) we can't expect a custom string to match, but I also believe that if somebody has custom needs he cannot expect a binary package.

[becker33]

In addition to binary installation, we also have plans to use the target to eventually inject compiler optimizations, like how gcc can take an -march=<target> argument (after we have more specific targets). We could always ignore strings that don't match a known target, but at that point it feels like giving the user rope with which to hang himself.

I think the crux of my concern is that I don't trust users to use caution with customization abilities that we provide them but that also conflict with other features. But that might be a philosophical difference that should be discussed more broadly on the upstream repo.

[alalazo]

We could always ignore strings that don't match a known target, but at that point it feels like giving the user rope with which to hang himself.

I would be fine if you warn me after you give me rope. I'll make sure I don't use it to hang myself 😄

But really, I don't have strong opinions on this. Honestly, if network and target detection were already in place and working correctly I don't know if I would have written these 10 lines.